Fehlerbehebung bei Autonomous Database on Dedicated Exadata Infrastructure

Use the following sections to help troubleshoot problems you have with Oracle Autonomous Database on Dedicated Exadata Infrastructure on Oracle Public Cloud and Exadata Cloud@Customer platforms.

Zugriff auf Masterverschlüsselungsschlüssel nicht möglich

Gilt nur für: Oracle Public Cloud (Anwendbar)

Mögliche Ursache

Das autonome Exadata-VM-Cluster (AVMC) kann den Masterverschlüsselungsschlüssel nicht erreichen.

Empfohlene Maßnahme

Prüfen Sie, ob der Masterverschlüsselungsschlüssel über den AVMC erreichbar ist.

Auflösung

  • Stellen Sie sicher, dass Servicegateway für das AVMC-Subnetz mit Ziel: Alle IAD-Services in Oracle Services Network aktiviert ist.
  • Stellen Sie sicher, dass die folgende IAM-Policy für die dynamische Gruppe definiert ist:
    allow dynamic-group <dynamic-group-name> 
    to manage keys 
    in compartment <vaults-and-keys-compartment>
    where all {
        target.key.id='<key_ocid>',        
        request.permission!='KEY_DELETE',
        request.permission!='KEY_MOVE',
        request.permission!='KEY_IMPORT',
        request.permission!='KEY_BACKUP’
    }

Auf Vault kann nicht zugegriffen werden

Gilt nur für: Oracle Public Cloud (Anwendbar)

Mögliche Ursache

Autonomes Exadata-VM-Cluster (AVMC) kann den Vault nicht lesen.

Empfohlene Maßnahme

Prüfen Sie, ob der Vault über den AVMC erreichbar ist.

Auflösung

  • Stellen Sie sicher, dass Servicegateway für das AVMC-Subnetz mit Ziel: Alle IAD-Services in Oracle Services Network aktiviert ist
  • Stellen Sie sicher, dass die folgende IAM-Policy für die dynamische Gruppe definiert ist
    allow dynamic-group <dynamic-group> 
    to read vaults 
    in tenancy | compartment <vaults-and-keys-compartment>

Backup in Network File System (NFS) nicht erfolgreich

Gilt nur für: Anwendbar Exadata Cloud@Customer

Mögliche Ursache

NFS-Ziel kann aufgrund eines Netzwerkproblems nicht erreichbar sein.

Empfohlene Maßnahme

Prüfen Sie, ob das NFS über das autonome Exadata-VM-Cluster-(AVMC-)Netzwerk erreichbar ist.

Auflösung

  • Prüfen Sie das Netzwerkrouting, und versuchen Sie es erneut. Alle IP-Adressen müssen über das Backupnetzwerk des AVMC erreichbar sein.
  • Trennen Sie die Verbindung, und hängen Sie das NFS erneut an.
  • Hängen Sie das freigegebene sekundäre NFS an.

Weitere Referenz

Dokumentation: Info zu Backup und Recovery

Netzwerkdateisystem (NFS) kann nicht gemountet werden

Gilt nur für: Anwendbar Exadata Cloud@Customer

Potenzielle Ursachen

  • Falscher Exportpfad.
  • Fehlende Berechtigungen für den Exportpfad.
  • Kein Netzwerkzugriff zwischen autonomen Exadata-VM-Cluster-(AVMC-)Client-IPs und NFS-Server.

Empfohlene Maßnahmen

  • Prüfen Sie den Exportpfad und die Berechtigungen für den Exportpfad.
  • Prüfen Sie, ob die Zugriffsports zwischen NFS-Server und Client-IPs geöffnet sind.

Auflösung

  • Stellen Sie sicher, dass die export_path korrekt ist.
  • Stellen Sie sicher, dass der Oracle-Benutzer über die Berechtigung für export_path verfügt
    • uid:gid des Oracle-Benutzers für das autonome VM-Cluster muss 1001:1001 lauten
  • Stellen Sie sicher, dass keine Firewalls den Netzwerkzugriff zwischen AVMC-Client-IPs und dem NFS-Server blockieren.
  • Wenn der Netzwerkzugriff auf NFS über Backup-IPs erfolgt, erstellen Sie eine Serviceanfrage für die Autonomous Database-Vorgänge, um Routingregeln zu implementieren, um Traffic über Backup-IPs an NFS umzuleiten.

Datei kann nicht in Network File System (NFS) geschrieben werden

Gilt nur für: Anwendbar Exadata Cloud@Customer

Mögliche Ursache

Falsche Berechtigungen für den NFS-Mount.

Empfohlene Maßnahme

Prüfen Sie, ob der NFS-Mount die richtigen Berechtigungen hat.

Auflösung

Stellen Sie sicher, dass der Oracle-Benutzer über die richtigen Berechtigungen für den NFS-Mount verfügt.
  • uid:gid des Oracle-Benutzers für das autonome VM-Cluster muss 1001:1001 lauten

Ausgehender Traffic kann nicht von APEX abgerufen werden

Fehlercode

OPC :ORA-24247 WHILE TRYING TO USE APEX_INSTANCE_ADMIN.VALIDATE_EMAIL_CONFIG

Mögliche Ursache

HTTPS- und SMTP-Egress-Regeln fehlen.

Empfohlene Maßnahme

Aktivieren Sie den Netzwerkzugriff für APEX entsprechend Ihren Anforderungen für Aufgaben wie das Senden von E-Mails oder den Zugriff auf REST- (oder andere HTTP-basierte) Ressourcen. Der Zugriff ist nur verfügbar, nachdem der Benutzer ihn konfiguriert hat.

Auflösung

So erteilen Sie Netzwerkzugriff über APEX (wie zuvor standardmäßig konfiguriert):
  • Der angegebene Principal-Name muss mit dem APEX-Installationsschema übereinstimmen. Beispiel: APEX_210200.
  • Der Name des Apex-Schemas für ein bestimmtes Deployment ist versionsabhängig und kann mit der folgenden Abfrage gefunden werden:
    select schema from dba_registry where comp_id='APEX'
  • Für andere Benutzer, wie ADMIN, erstellte ACLs wirken sich nicht auf den Zugriff über APEX aus. Solche ACLs würden sich nur auf Anwendungsfälle auswirken, in denen ADMIN oder Code, der dem ADMIN direkt als UTL_HTTP oder UTL_SMTP gehört, direkt aufgerufen wird.

Weitere Referenz

Probleme bei der Backupaufbewahrung mit ZDLRA

Gilt nur für: Anwendbar Exadata Cloud@Customer

Mögliche Ursache

Die Ursache hängt von den Details im Diagnosebericht ab, die gemäß den folgenden Vorschlägen generiert wurden.

Empfohlene Maßnahme

  • Um uns zu helfen, das Problem zu verstehen und zu beheben, folgen Sie bitte dem folgenden My Oracle Support (MOS)-Hinweis, der Sie durch die Erfassung von Diagnosedaten erklärt. Dadurch kann Support die Ursache Ihres Problems eingrenzen.

    Systemaktivitätsbericht: SRDC - Zero Data Loss Recovery Appliance (ZDLRA) Data Collection (Dok.-ID 2154189.1)

  • Wenn die Recovery Appliance höher als oder gleich Version 19.2.1.1.2 ist, kann der folgende Befehl auch verwendet werden, um den Systemaktivitätsbericht (SAR) zu generieren. Dieser wird jedoch nur im Textformat generiert:
    racli run diagnostics --tag=sar

    Dieser Befehl generiert ein Diagnosepackage.

  • Senden Sie eine Serviceanfrage in My Oracle Support mit den Diagnoseergebnissen.

Auflösung

Nachdem Sie die Serviceanfrage mit den Diagnoseergebnissen eingereicht haben, wird sich das Oracle Support-Team mit Ihnen in Verbindung setzen, um das entsprechende Problem zu lösen.

Weitere Referenz

Verzögerung bei der Verbindung zu Autonomous Database mit SQL*Plus

Potenzielle Ursache

Wenn Sie versuchen, eine Verbindung zu Autonomous Database on Dedicated Exadata Infrastructure mit SQL*Plus herzustellen, wird versucht, ONS auf Port 6200 zu erreichen, um FAN-Ereignisse einmal pro Knoten zu abonnieren. Wenn die Anforderung zum Erreichen des Knotens 6200 aufgrund eines Timeouts nach 10 Sekunden (pro Knoten) abläuft, wird mit regulärem SQLNET 1521/2484 fortgefahren, was zu einer Verbindungsverzögerung führt.

Möglicherweise haben Sie einen blockierten Ingress auf der domU für Port 6200 oder einen blockierten Egress auf dem Clienthost.

Empfohlene Maßnahme

Geben Sie Ingress- und Egress-Regeln für FAN-Port 6200 an, oder deaktivieren Sie das Abonnement für FAN-Ereignisse auf Ihrem Client.

Auflösung

Sie haben zwei Optionen, um dieses Problem zu beheben:
  • Deaktivieren Sie das Abonnement für FAN-Ereignisse auf Ihrem Client, indem Sie die XML-Datei oraaccess aktualisieren.

    Mit der Datei oraaccess.xml können Sie die verbindungsspezifischen Parameter basierend auf den individuellen Anwendungsanforderungen außer Kraft setzen. Beispiele finden Sie unter Verbindungsparameter auf Verbindungs-String-Ebene außer Kraft setzen.

  • Fix connectivity to port 6200 from the client host to domU by providing the ingress and egress rules for FAN port 6200 as described in Step 4. Create the VCN and Subnets.