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 ()
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’ }
Weitere Referenz
Auf Vault kann nicht zugegriffen werden
Gilt nur für: Oracle Public Cloud ()
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>
Weitere Referenz
Backup in Network File System (NFS) nicht erfolgreich
Gilt nur für: 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: 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: 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
- 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
- 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
- Dokumentation mit der Platzhalterregel, die Zugriff auf Hosts zulassen würde, und einer nachfolgenden restriktiveren Regel, die localhost-Zugriff zulässt: Netzwerkservices in Oracle Database aktivieren
- Weitere Details zum Hinzufügen von Regeln zum Zulassen bestimmter Hosts oder Platzhaltermuster finden Sie unter APPEND_HOST_Procedure in der Oracle Database 19c PL/SQL Packages and Types Reference oder in der Oracle Database 23ai PL/SQL Packages and Types Reference.
Probleme bei der Backupaufbewahrung mit ZDLRA
Gilt nur für: 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.
- 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
- Dokumentation: Serviceanfrage in My Oracle Support erstellen
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
-
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.