Problembeschreibung: Mindestens ein VM-Gastdateisystem verfügt über weniger als 10% freien Speicherplatz.

Risiko: Nicht genügend freier Speicherplatz im VM-Gastdateisystem kann zu Fehlern bei der Zuweisung von Datenträgerspeicherplatz führen. Dies kann verschiedene Fehler in der Oracle-Software (Datenbank, Clusterware, Cloud, Exadata) zur Folge haben.

Maßnahme:

Oracle Cloud- und Exadata-Utilitys werden automatisch ausgeführt, um alte von der Oracle-Software erstellte Logdateien und Tracedateien zu löschen und Speicherplatz im Dateisystem freizugeben.

Wenn die Utilitys zur automatischen Speicherplatzfreigabe im Dateisystem nicht genügend alte Dateien löschen können, um dieses Ereignis zu beheben, führen Sie die folgenden Aktionen aus:

1. Entfernen Sie nicht erforderliche Dateien und/oder Verzeichnisse, die manuell oder von vom Kunden installierten Anwendungen oder Utilitys erstellt wurden. Dateien, die von der vom Kunden installierten Software erstellt wurden, fallen nicht in den Anwendungsbereich der automatischen Utilitys von Oracle für die Speicherplatzfreigabe in Dateisystemen. Der folgende Betriebssystembefehl, der als Benutzer opc ausgeführt wird, eignet sich zum Ermitteln von Verzeichnissen, die übermäßig viel Speicherplatz belegen:

   $ sudo du -hx file-system-mount-point | sort -hr

   Entfernen Sie nur Dateien oder Verzeichnisse, von denen Sie wissen, dass sie sicher entfernt werden können.

2. Geben Sie Datenträgerspeicherplatz im Dateisystem /u02 frei, indem Sie Datenbank-Homes entfernen, die keine Datenbanken enthalten. Weitere Informationen zur Verwaltung von Datenbank-Homes finden Sie unter Oracle Database Homes in Exadata Database Service on Exadata Cloud Infrastructure-Instanzen verwalten.
3. Öffnen Sie eine Serviceanfrage, um zusätzliche Anleitungen zur Reduzierung der Speicherplatzbelegung im Dateisystem zu erhalten.

Problembeschreibung: Der Cluster Ready-Stack befindet sich im Offlinestatus oder ist nicht erfolgreich.

Risiko: Wenn der Cluster Ready Service auf einem Knoten offline ist, kann der Knoten keine Datenbankservices für die Anwendung bereitstellen.

Maßnahme:

1. Prüfen Sie, ob CRS vom Administrator als Teil eines geplanten Wartungsereignisses oder einer vertikalen Skalierung des lokalen Speichers gestoppt wurde.
   1. Die folgenden Patching-Ereignisse stoppen CRS:
      1. GRID-Patching
      2. Exadata-VM-Patching des Gasts
      3. Exadata-VM-Patching des Hosts
2. Wenn CRS unerwartet gestoppt wurde, kann der aktuelle Status mit dem Befehl crsctl check crs geprüft werden.
   1. Wenn der Knoten nicht antwortet, wird der VM-Knoten möglicherweise neu gestartet. Warten Sie, bis der Neustart des Knotens abgeschlossen ist. CRS wird normalerweise über den Prozess init gestartet.
3. Wenn CRS noch heruntergefahren ist, prüfen Sie die Fehlerursache im alert.log in /u01/app/grid/diag/crs/<node_name>/crs/trace.

   Prüfen Sie die Logeinträge für das Datum/die Uhrzeit des "Heruntergefahren"-Ereignisses. Führen Sie ggf. die Korrekturvorschläge aus.

4. Starten Sie CRS mit dem Befehl crsctl start crs neu.
5. Bei einem erfolgreichen Neustart von CRS wird das Behebungsereignis generiert: AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED.

Problembeschreibung: Ein SCAN-Listener ist heruntergefahren und kann keine Anwendungsverbindungen akzeptieren.

Risiko: Wenn alle SCAN-Listener heruntergefahren sind, können keine Anwendungsverbindungen zur Datenbank über den SCAN-Listener hergestellt werden.

Maßnahme:

Starten Sie den SCAN-Listener, um das Ereignis DOWN_CLEARED zu empfangen.

DOWN-Ereignis des Typs INFORMATION

1. Wenn das Ereignis durch eine Oracle Cloud-Wartungsaktion wie das Ausführen eines Grid Infrastructure-Softwareupdates verursacht wurde, ist keine Aktion erforderlich. Der betroffene SCAN-Listener führt automatisch einen Failover auf eine verfügbare Instanz durch.
2. Wenn das Ereignis durch eine Benutzeraktion verursacht wurde, starten Sie den SCAN-Listener bei der nächsten Gelegenheit.

DOWN-Ereignis des Typs CRITICAL

Prüfen Sie den SCAN-Status, und starten Sie den SCAN-Listener neu.

1. Melden Sie sich als Benutzer opc bei der VM an, und wechseln Sie mit sudo zum Benutzer grid:

    sudo su - grid

2. Prüfen Sie den SCAN-Listener-Status auf einem beliebigen Knoten:

    srvctl status scan_listener 

3. Starten Sie den SCAN-Listener.

    srvctl start scan_listener

4. Prüfen Sie den SCAN-Listener-Status auf einem beliebigen Knoten erneut:

   Wenn scan_listener noch heruntergefahren ist, prüfen Sie die Ursache für den Scan Listener-Fehler:

   1. Erfassen Sie die CRS- und Betriebssystemlogs 30 Minuten davor und 10 Minuten danach für den im Log angegebenen <hostName>. Beachten Sie, dass die Zeit in der Ereignis-Payload immer in UTC angegeben wird. Passen Sie für die tfactl-Erfassung die Zeit entsprechend der Zeitzone des VM-Clusters an. Als Grid-Benutzer:

       tfactl diagcollect -crs -os -node <hostName> –from "<eventTime adjusted for local vm timezone> - 30 minute " -to "<eventTime adjusted for local vm timezone> + 10 minutes"

   2. Prüfen Sie das SCAN-Listener-Log unter /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace.

Problembeschreibung: Ein Client-Listener ist heruntergefahren und kann keine Anwendungsverbindungen akzeptieren.

Maßnahme:

Starten Sie den Client-Listener, um das Ereignis DOWN_CLEARED zu empfangen.

DOWN-Ereignis des Typs INFORMATION

1. Wenn das Ereignis durch eine Oracle Cloud-Wartungsaktion wie das Ausführen eines Grid Infrastructure-Softwareupdates verursacht wurde, ist keine Aktion erforderlich. Der betroffene Client-Listener wird automatisch neu gestartet, wenn die Wartung, die sich auf die Grid-Instanz auswirkt, abgeschlossen ist.
2. Wenn das Ereignis durch eine Benutzeraktion verursacht wurde, starten Sie den Client-Listener bei der nächsten Gelegenheit.

DOWN-Ereignis des Typs CRITICAL

Prüfen Sie den Client-Listener-Status, und starten Sie dann den Client-Listener neu.

1. Melden Sie sich als Benutzer opc bei der VM an, und wechseln Sie mit sudo zum Benutzer grid:

   [opc@vm ~] sudo su - grid

2. Prüfen Sie den Client-Listener-Status auf einem beliebigen Knoten:

   [grid@vm ~] srvctl status listener 

3. Starten Sie den Client-Listener:

   [grid@vm ~] srvctl start listener

4. Prüfen Sie den Client-Listener-Status auf einem beliebigen Knoten erneut:

   Wenn der Client-Listener noch heruntergefahren ist, untersuchen Sie die Ursache des Client-Listener-Fehlers:

   1. Erfassen Sie mit tfactl die CRS- und Betriebssystemlogs 30 Minuten davor und 10 Minuten danach für den im Log angegebenen <hostName>. Beachten Sie, dass die Zeit in der Ereignis-Payload immer in UTC angegeben wird. Passen Sie für die tfactl-Erfassung die Zeit entsprechend der Zeitzone des VM-Clusters an.

      [grid@vm ~] tfactl diagcollect -crs -os -node <hostName> –from "<eventTime adjusted for local vm timezone> - 30 minute " -to "<eventTime adjusted for local vm timezone> + 10 minutes"

   2. Prüfen Sie das Listener-Log unter /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace.

Problembeschreibung: Eine Datenbankinstanz wurde heruntergefahren.

Risiko: Eine Datenbankinstanz wurde heruntergefahren. Dies kann zu einer verringerten Performance führen, wenn Datenbankinstanzen auf anderen Knoten im Cluster verfügbar sind, oder zu einer Ausfallzeit für das ganze System, wenn die Datenbankinstanzen auf allen Knoten heruntergefahren sind.

Maßnahme:

Starten Sie die Datenbankinstanz, um das Ereignis DOWN_CLEARED zu empfangen.

DOWN-Ereignis des Typs CRITICAL

1. Prüfen Sie den Datenbankstatus, und starten Sie die heruntergefahrene Datenbankinstanz neu.
   1. Melden Sie sich als Benutzer oracle bei der VM an:
   2. Legen Sie die Umgebung fest:

      [oracle@vm ~] . <dbName>.env

   3. Prüfen Sie den Datenbankstatus:

      [oracle@vm ~] srvctl status database -db <dbName>

   4. Starten Sie die Datenbankinstanz:

      [oracle@vm ~] srvctl start instance -db <dbName> -instance <instanceName>

2. Untersuchen Sie die Ursache des Fehlers bei der Datenbankinstanz.
   1. Prüfen Sie die Trace File Analyzer-(TFA-)Ereignisse für die Datenbank:

      [oracle@vm ~] tfactl events -database <dbName> -instance <instanceName>

   2. Prüfen Sie das Datenbankalertlog unter $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log

Problembeschreibung: Oracle Clusterware ist so konzipiert, dass bei Erkennung eines kritischen Problems eine Knotenentfernung durchgeführt wird. Dazu werden ein oder mehrere Knoten aus dem Cluster entfernt. Ein kritisches Problem kann sein: ein Knoten antwortet nicht über einen Netzwerk-Heartbeat, ein Knoten antwortet nicht über einen Datenträger-Heartbeat, ein hängender oder stark beeinträchtigter Rechner oder ein hängender ocssd.bin-Prozess. Der Zweck dieser Knotenentfernung besteht darin, den Gesamtzustand des Clusters aufrechtzuerhalten, indem beeinträchtigte Member entfernt werden.

Risiken: Während des Neustarts des entfernten Knotens kann der Knoten keine Datenbankservices für die Anwendung bereitstellen.

Maßnahme: Die CRS-Knotenentfernung kann durch OCSSD-(CSS-Daemon-), CSSDAGENT- oder CSSDMONITOR-Prozesse verursacht werden. Dazu müssen Sie bestimmen, welcher Prozess für die Knotenentfernung verantwortlich war, und die relevanten Logdateien prüfen. Häufige Ursachen für die OCSSD-Entfernung sind Netzwerkausfälle/-latenzen, I/O-Probleme bei CSS-Voting Disks, eine Mitgliederabbrucheskalation. CSSDAGENT- oder CSSDMONITOR-Entfernungen können ein BS-Scheduler-Problem oder ein hängender Thread innerhalb des CSS-Daemons sein.

Zu den zu prüfenden Logdateien gehören:

• Clusterware-Alertlog
• cssdagent-Log
• cssdmonitor-Log
• ocssd-Log
• lastgasp-Log
• /var/log/messages
• CHM/OS Watcher-Daten
• opatch lsinventory-Details

Weitere Informationen zum Erfassen der meisten Dateien finden Sie unter Autonomous Health Framework (AHF) - Including TFA and ORAchk/EXAchk (Dok.-ID 2550798.1).

Weitere Informationen zur Fehlerbehebung bei CRS-Knotenentfernung finden Sie unter Troubleshooting Clusterware Node Evictions (Reboots) (Dok.-ID 1050693.1).

Problembeschreibung: Beschädigungen können zu Anwendungs- oder Datenbankfehlern und im schlimmsten Fall zu erheblichen Datenverlusten führen, wenn sie nicht sofort behoben werden.

Weitere Informationen finden Sie unter Physical and Logical Block Corruptions. All you wanted to know about it. (Dok.-ID 840978.1).

Risiko: Ein Ausfall durch Datenbeschädigung tritt ein, wenn eine Hardware-, Software -oder Netzwerkkomponente das Lesen oder Schreiben fehlerhafter Daten verursacht. Die Auswirkungen eines Ausfalls durch Datenbeschädigung auf Serviceebene können von einem kleinen Teil der Anwendung oder Datenbank (eventuell nur einem Datenbankblock) bis zu einem großen Teil der Anwendung oder Datenbank reichen (wodurch diese im Wesentlichen unbrauchbar wird). Wenn die Korrekturmaßnahme nicht sofort ergriffen wird, steigt das Risiko potenzieller Ausfallzeiten und Datenverluste.

Maßnahme:

Die Benachrichtigung über aktuelle Ereignisse wird gegenwärtig bei physischen Blockbeschädigungen (ORA-01578), verlorenen Schreibvorgängen (ORA-00752, ORA-00753 und ORA-00600 mit erstem Argument 3020) und logischen Beschädigungen (typisch ermittelt aus ORA-00600 mit erstem Argument kdsgrp1, kdsgrp1, kclchkblk_3, 13013 OR 5463) ausgelöst.

Problembeschreibung: CDB-RAC-Instanz kann vorübergehend oder dauerhaft blockiert werden, weil der Log Writer (LGWR) die Logpuffer nicht in ein Online-Redo-Log schreiben kann. Dies liegt daran, dass alle Onlinelogs archiviert werden müssen. Sobald der Archiver (ARC) mindestens ein Online-Redo-Log archivieren kann, kann LGWR die Logpuffer wieder in Online-Redo-Logdateien schreiben, und die Auswirkungen auf Anwendungen werden verringert.

Risiko: Wenn der Archiver vorübergehend hängt, kann dies zu einem geringfügigen Anwendungs-Brownout oder zur Blockierung von Anwendungsprozessen führen, die versuchen, ihre Datenbankänderungen festzuschreiben. Wenn die Blockierung des Archivers nicht aufgehoben wird, kann es bei Anwendungen zu einer längeren Verarbeitungsverzögerung kommen.

1. Fügen Sie für jeden Thread eine Redo-Loggruppe hinzu. Das zusätzliche Redo-Log muss gleich groß sein wie das aktuelle Log.
   1. Verwenden Sie die folgende Abfrage:

      select max(group#) Ending_group_number, thread#, count(*) number_of_groups_per_thread, bytes redo_size_in_bytes from v$log group by thread#,bytes

   2. Fügen Sie eine neue Gruppe pro Thread mit derselben Größe wie die aktuellen Redo-Logs hinzu.

      alter database add logfile thread <thread_number> Group <max group + 1> ('<DATA_DISKGROUP>') size <redo_size_in_bytes>

2. Ändern Sie die Größe der Online-Redo-Logs, indem Sie größere Redo-Logs hinzufügen und die aktuellen kleineren Redo-Logs löschen.
   1. Verwenden Sie die folgende Abfrage:

      select max(group#) Ending_group_number, thread#, count(*) number_of_groups_per_thread, bytes redo_size_in_bytes from v$log group by thread#,bytes

   2. Fügen Sie für jeden aktuell vorhandenen Thread <number_of_groups_per_thread> dieselbe Anzahl von Redo-Logs hinzu. Die <new_redo_size_in_bytes> muss den Angaben unter Online-Redo-Logs richtig konfigurieren, Abschnitt "Oracle Database High Availability - Überblick und Best Practices" entsprechen.

      1. alter database add logfile thread <thread_number> Group <max group + 1> ('<DATA_DISKGROUP>') size <new_redo_size_in_bytes>

      2. Die ursprünglichen kleineren Redo-Logs müssen gelöscht werden. Ein Redo-Log kann nur gelöscht werden, wenn es den Status "Inaktiv" hat.

         So bestimmen Sie den Status eines Problems mit Redo- Logs:

         select group#, thread#, status, bytes from v$log order by bytes, group#, thread#;

         So löschen Sie die ursprünglichen kleineren Redo-Logs:

         alter database drop logfile <group#>

• Wenn die Datenbank hängt, sind das primäre Logarchivziel und die Alternative möglicherweise voll. Einzelheiten zum Freigeben von Speicherplatz in RECO- und DATA-Datenträgergruppen finden Sie unter HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE.

Problembeschreibung: Der Hang Manager hat einen hängenden Prozess ermittelt und eine Fehlermeldung ORA-32701 generiert. Darüber hinaus kann dieses Ereignis ausgelöst werden, wenn der Diagnoseprozess (DIA0) einen hängenden kritischen Datenbankprozess ermittelt.

Risiko: Eine Blockierung kann auf Probleme mit der Ressource, dem Betriebssystem oder der Anwendungscodierung hinweisen.

Maßnahme:

Problembeschreibung: Ein tägliches inkrementelles BACKUP der CDB war nicht erfolgreich.

Risiko: Ein Fehler beim Backup kann dessen Verwendbarkeit für Wiederherstellung/Recovery der Datenbank beeinträchtigen. Er kann sich auf das Recovery Point Object (RPO) und das Recovery Time Object (RTO) auswirken.

Maßnahme:

Prüfen Sie die RMAN-Logs, die dem Datum/der Uhrzeit des Ereignisses entsprechen. Beachten Sie, dass sich der Ereigniszeitstempel <eventTime> auf UTC bezieht, und passen Sie ihn gegebenenfalls für die Zeitzone der VM an.

• Für von Oracle verwaltete Exadata Cloud Infrastructure-Backups oder benutzerkonfigurierte Backups unter dbaascli:
  • Die RMAN-Ausgabe finden Sie unter /var/opt/oracle/log/<DB_NAME>/obkup.

    Tägliche inkrementelle Logs weisen das Format obkup_yyyy-mm-dd_24hh:mm:ss.zzzzzzzzzzzz.log auf und werden im Verzeichnis obkup gespeichert. Die Logs befinden sich auf dem bei Initiierung des Backups niedrigsten aktiven Knoten/der niedrigsten Instanz der Datenbank.

  • Prüfen Sie im Log, ob Fehler aufgetreten sind:
    • Wenn der Fehler auf ein externes Ereignis außerhalb von RMAN zurückzuführen ist, z.B. einen vollen Backupspeicherort oder ein Netzwerkproblem, beheben Sie das externe Problem.

    • Stellen Sie bei anderen RMAN-Skriptfehlern die Diagnoselogs zusammen, und öffnen Sie eine Serviceanfrage. Siehe DBAAS-Tooling: Mit dbaascli Cloud-Tooling-Logs erfassen und Cloud-Tooling-Health Check durchführen.

  • Wenn das Problem vorübergehend auftritt oder behoben ist, erstellen Sie ein neues inkrementelles Backup: Siehe dbaascli database backup.

• Vom Kunden verwaltetes Backup mit RMAN:
  • Prüfen Sie die RMAN-Logs für das Backup.

Problembeschreibung: Die Speicherplatzbelegung der ASM-Datenträgergruppe beträgt oder überschreitet 90%.

Risiko: Unzureichender Speicherplatz in ASM-Datenträgergruppen kann zu einem Fehler beim Erstellen von Datenbanken, Tablespaces und Datendateien, einem Fehler bei der automatischen Datendateierweiterung oder einem Fehler beim ASM-Rebalancing führen.

Maßnahme:

[opc@node ~] sudo su - grid
[grid@node ~] sqlplus / as sysasm
 
SQL> select 'ora.'||name||'.dg', total_mb, free_mb, round ((1-(free_mb/total_mb))*100,2) pct_used from v$asm_diskgroup;
 
NAME                             TOTAL_MB    FREE_MB   PCT_USED
------------------------------ ---------- ---------- ----------
ora.DATAC1.dg                    75497472    7408292      90.19
ora.RECOC1.dg                    18874368   17720208       6.11

Die Kapazität der ASM-Datenträgergruppen kann wie folgt erhöht werden:

1. Den Exadata-VM-Clusterspeicher skalieren, um mehr ASM-Datenträgergruppenkapazität hinzuzufügen. Siehe Exadata Cloud Infrastructure-Instanz skalieren.
2. Den Exadata-Infrastrukturspeicher skalieren, um mehr ASM-Datenträgergruppenkapazität hinzuzufügen. Siehe Compute- und Speicherressourcen von Exadata X8M und X9M skalieren.

Die Speicherplatzbelegung von DATA-Datenträgergruppen wie folgt reduziert werden:

1. Nicht verwendete Datendateien und temporäre Dateien aus Datenbanken löschen. Siehe Datendateien löschen.
2. Nicht verwendete Datenbanken (z.B. Testdatenbanken) beenden. Siehe Datenbank mit der Konsole beenden.

Die Speicherplatzbelegung von RECO-Datenträgergruppen kann wie folgt reduziert werden:

1. Unnötige garantierte Restore Points löschen. Siehe Normale und garantierte Restore Points verwenden.
2. Archivierte Redo-Logs oder Datenbankbackups löschen, die bereits außerhalb des Flash Recovery-Bereichs (FRA) gesichert wurden. Siehe Fast Recovery-Bereich verwalten.

Die Speicherplatzbelegung für SPARSE-Datenträgergruppen kann wie folgt reduziert werden:

1. Vollständig kopierte Testmasterdatenbanken in eine andere Datenträgergruppe (z.B. DATA) verschieben.
2. Nicht verwendete Snapshot-Datenbanken oder Testmasterdatenbanken löschen. Siehe Exadata-Snapshots verwalten.

Weitere Informationen zur Verwaltung der Log- und Diagnosedateien finden Sie unter Log- und Diagnosedateien in Oracle Exadata Database Service on Dedicated Infrastructure verwalten.

Die Softwarekomponenten in Oracle Exadata Database Service on Dedicated Infrastructure generieren zahlreiche Log- und Diagnosedateien. Nicht alle diese Dateien werden automatisch archiviert und gelöscht. Daher ist es eine wichtige administrative Aufgabe, die Identifizierung und Entfernung dieser Dateien zu verwalten, damit der Dateispeicher nicht knapp wird.

Datenbank-Deployments auf ExaDB-D umfassen das Skript cleandblogs, das diese administrativen Aufgabe vereinfacht. Das Skript wird täglich als cron-Job auf jedem Compute Node ausgeführt, um Schlüsseldateien zu archivieren und alte Log- und Diagnosedateien zu entfernen.

Das Skript cleandblogs wird mit dem adrci-Tool (Automatic Diagnostic Repository [ADR] Command Interpreter) ausgeführt, um Zieldiagnoseordner und -dateien für jedes Oracle Home in /etc/oratab zu identifizieren und zu löschen. Es ist auch für Oracle Net Listener-Logs, Auditdateien und Coredumps bestimmt.

In ExaDB-D wird das Skript separat als Benutzer oracle ausgeführt, um Log- und Diagnosedateien zu bereinigen, die mit Oracle Database verknüpft sind, und als Benutzer grid, um Log- und Diagnosedateien zu bereinigen, die mit Oracle Grid Infrastructure verknüpft sind.

Das Skript cleandblogs verwendet eine Konfigurationsdatei, um zu bestimmen, wie lange die einzelnen Log- oder Diagnosedateien aufbewahrt werden sollen. Sie können die Datei bearbeiten, um die Standardaufbewahrungszeit zu ändern. Die Datei befindet sich unter /var/opt/oracle/cleandb/cleandblogs.cfg auf jedem Compute Node.

Problembeschreibung: Zu viel VM-Arbeitsspeicher ist HugePages zugewiesen.

Risiko: Wenn HugePages zu viel Arbeitsspeicher zugewiesen ist, kann schlechte Datenbankperformance, Speichermangel für das System, übermäßiges Swapping oder ein Ausfall wichtiger Systemservices die Folge sein, was zu Systemabstürzen oder Knotenentfernung führen kann.

Maßnahme:

1. Reduzieren Sie die Speicherbelegung durch HugePages. Die richtige Einstellung für den Betriebssystemparameter vm.nr_hugepages finden Sie im My Oracle Support-Dokument 361323.1.
2. Skalieren Sie den VM-Arbeitsspeicher vertikal. Weitere Informationen zur Skalierung des VM-Arbeitsspeichers finden Sie unter Einführung in das vertikale oder horizontale Skalieren.

Problembeschreibung: Unerwartete SSHD-Konfiguration.

Risiko: Die SSHD-Konfiguration ist unerwartet. Dies kann zu einem Fehler bei der Oracle Cloud-Automatisierung führen oder den SSH-Zugriff des Kunden auf die VM verhindern.

Maßnahme: Ändern Sie SSHD entsprechend der erwarteten Konfiguration.

1. Prüfen Sie, ob der SSHD-Service aktiv ist.

   $ sudo systemctl is-active sshd.service
   active

   Wenn der SSHD-Service inaktiv ist, starten Sie ihn.

   $ sudo systemctl start sshd.service

2. Prüfen Sie, ob der SSHD-Service aktiviert wurde.

   $ sudo /opt/oracle.cellos/host_access_control ssh-service --status
   [INFO] [IMG-SEC-1201] Service sshd is enabled {1}

   Wenn der SSHD-Service deaktiviert ist, aktivieren Sie ihn.

   $ sudo /opt/oracle.cellos/host_access_control ssh-service --enable

3. Ändern Sie die SSHD-Konfiguration so, dass sie den erwarteten Werten gemäß der Tabelle im Abschnitt "Problembeschreibung" weiter oben entspricht.

   SSHD-Konfigurationseinstellung	So ändern Sie die aktuelle Einstellung
   Ciphers	/opt/oracle.cellos/host_access_control sshciphers --help
   MACs	/opt/oracle.cellos/host_access_control ssh-macs --help
   PermitRootLogin	/opt/oracle.cellos/host_access_control rootssh --help
   ClientAliveInterval	/opt/oracle.cellos/host_access_control idle-timeout --help
   ClientAliveCountMax	/opt/oracle.cellos/host_access_control idle-timeout --help
   ListenAddress	/opt/oracle.cellos/host_access_control ssh-listen --help
   ALLE ANDEREN PARAMETER	Bearbeiten Sie /etc/ssh/sshd_config. Starten Sie sshd.service neu: $ sudo systemctl restart sshd.service

Problembeschreibung: In ein Dateisystem, das nicht schreibgeschützt sein sollte, kann nicht mehr geschrieben werden.

Risiko: Oracle-Software (Linux, Database, Clusterware, Cloud, Exadata) erfordert Schreibzugriff auf Dateisysteme, damit sie ordnungsgemäß funktioniert.

Maßnahme:

Dateisysteme /u01- und /u02:

1. Stoppen Sie gegebenenfalls gestartete Services, die das Dateisystem verwenden, wie Oracle Clusterware, Trace File Analyzer (TFA) und Enterprise Manager-(EM-)Agent.
2. Unmounten Sie das Dateisystem.
3. Prüfen und reparieren Sie das Dateisystem.
   • ext4: Weitere Informationen finden Sie unter Dateisystem prüfen und reparieren.
   • XFS: Weitere Informationen finden Sie unter XFS-Dateisystem prüfen und reparieren.
   • Wenn das Dateisystem nicht repariert werden kann, erstellen Sie eine Serviceanfrage bei Oracle Support.
4. Mounten Sie das Dateisystem.
5. Starten Sie die Services.

/-(root-)Dateisystem:

Erstellen Sie eine Serviceanfrage bei Oracle Support.

• Wenn VM-Zugriff besteht, erfassen Sie die vollständige Ausgabe des Befehls dmesg(1), und geben Sie sie an Oracle Support weiter.
• Beachten Sie, dass die Reparatur des /-(Root-)Dateisystems nur mit Konsolenzugriff möglich ist.

Problembeschreibung: Eine CRITICAL-EXAchk-Prüfung war nicht erfolgreich. Das Problem muss so schnell wie möglich geprüft und behoben werden.

Risiko: Es wird erwartet, dass eine CRITICAL-Prüfung Auswirkungen auf eine große Anzahl von Kunden hat. Das Problem muss sofort (z.B. innerhalb von 24 Stunden) behoben werden. Das Problem erfüllt mindestens eines der folgenden Kriterien:

1. Beschädigung oder Datenverlust auf Datenträger
2. Sporadische falsche Ergebnisse bei Nutzung eines Exadata-Features (z.B. Smart Scan)
3. Systemweite Beeinträchtigung der Verfügbarkeit
4. Schwerwiegende systemweite Auswirkungen auf die Performance, was sich erheblich auf Service Level Agreements (SLAs) für Anwendungen auswirkt
5. Einschränkung der Redundanz und Unfähigkeit, die Redundanz wiederherzustellen
6. Keine Möglichkeit, Software im Rolling-Modus zu aktualisieren
7. Konfigurationsfehler, der zu einer unerwarteten oder unbekannten Auswirkung führen könnte

Maßnahme:

Es wird empfohlen, den HTML-Bericht von EXAchk aus der neuesten EXAchk-ZIP-Datei zu prüfen. Klicken Sie in jeder CRITICAL-Prüfung auf Anzeigen, und befolgen Sie die Empfehlungen, die Folgendes enthalten: Nutzen/Auswirkung, Risiko und Leitfaden zu Maßnahmen/Reparatur. Sobald das CRITICAL-Prüfungsergebnis behoben wurde, wird diese Prüfung beim nächsten EXAchk-Lauf erfolgreich abgeschlossen. Weitere Informationen zu Oracle EXAchk finden Sie unter Oracle Exadata Database Machine EXAchk (Dok.-ID 1070954.1).

/usr/bin/exachk -profile exatier1 -noupgrade -dball

Wenn die Prüfergebnisse falsche Daten zurückgeben, erstellen Sie eine Serviceanfrage.

Wenn eine CRITICAL-Prüfung vorliegt, die vorübergehend ausgeschlossen werden muss, befolgen Sie die Anweisungen im Abschnitt Skipping Specific Best Practice Checks in Exadata Cloud in Oracle Exadata Database Machine EXAchk (Dok.-ID 1070954.1).

Problemanweisung: Eine höhere I/O-Latenz kann zu erheblichen I/O-Problemen führen.

Risiko: Eine erhöhte I/O-Latenz führt direkt zu langsameren Datenbankvorgängen und Antwortzeiten für SQL-Abfragen. Eine hohe Latenz kann insbesondere bei OLTP-Workloads zu einer erheblichen Beeinträchtigung der Datenbankperformance führen.

Aktion: Befolgen Sie die My Oracle Support-(MOS-)Hinweise 2119510.1 und 2530864.1, um physische Lese-Waits mit einem einzelnen Block mit hoher Zelle auf Exadata zu untersuchen.

Problemanweisung: Hohe Werte für die Wait-Anzahl der I/O-Wait-Klasse von mehr als 32 ms können auf ein potenzielles Problem mit der zugrunde liegenden Exadata-Infrastruktur hinweisen.

Risiko: Eine erhöhte I/O-Latenz führt direkt zu langsameren Datenbankvorgängen und Antwortzeiten für SQL-Abfragen. Hohe Latenz kann erhebliche Auswirkungen haben.

Aktion: Befolgen Sie die My Oracle Support-(MOS-)Hinweise 2119510.1 und 2530864.1, um physische Lese-Waits mit einem einzelnen Block mit hoher Zelle auf Exadata zu untersuchen.

Problemanweisung: CPU-intensive CDB/PDB-Sessions, die länger als 300 Sekunden auf Latch/Cursor-bezogene Wait-Ereignisse warten, und CPU-intensive CDB/PDB-Sessions, die länger als 900 Sekunden auf Wait-Ereignisse im Library-Cache warten.

Risiko: Diese CPU-intensiven Wait-Ereignisse wirken sich im Allgemeinen auf die gesamte Systemperformance aus. Da Mutexe CPU-intensive Ressourcen sind, kann die CPU-Auslastung im Falle von Mutex-Konflikten steigen und sich auf Benutzersessions auswirken.

Aktion: Um hohe CPU-intensive Waits in der Datenbank zu untersuchen, befolgen Sie die My Oracle Support-(MOS-)Hinweise: 1349387.1, 1357946.1, 1377998.1 und 444560.1, die spezifische Hinweise zur Fehlerbehebung für verschiedene Szenarios enthalten.

Problemanweisung: Das Vordergrundwarteereignis verbraucht mehr als 20% der gesamten DB-Zeit, ausgenommen die Wait-Ereignisklasse "IDLE" und Exadata-Benutzer-I/O-Warteereignisse. Allein das Exadata-Benutzer-I/O-Warteereignis macht mehr als 35% der gesamten DB-Zeit aus.

Risiko: Hohe Warteereigniszeiten weisen darauf hin, dass die Datenbank viel Zeit mit dem Warten auf Ressourcen, Prozesse oder I/O-Vorgänge aufwendet, was zu Performanceengpässen und potenziell Auswirkungen auf die Reaktionsfähigkeit der Anwendung führt.

Aktion: Um High Waits in der Datenbank zu untersuchen, befolgen Sie die My Oracle Support-(MOS-)Hinweise: 1377446.1.

Problemanweisung: Übermäßiges CPU-Throttling in der Datenbank beobachtet.

Risiko: Übermäßige CPU-Throttling-Vorgänge in der Datenbank können auftreten, wenn die Resource Manager-Limits nicht mit der Nutzungsgruppenauslastung übereinstimmen, was möglicherweise zu Performanceproblemen führt. Wenn die Drosselung häufig auftritt, kann dies zu Performanceproblemen führen, wie langsamen Abfragen oder Antwortzeiten der Anwendung.

Aktion: Um ein übermäßiges CPU-Throttling in der Datenbank zu beheben, befolgen Sie die My Oracle Support-(MOS-)Hinweise: 1339769.1.

Problemanweisung: Die RECO-Datenträgergruppe des VM-Clusters oder die FAST RECOVERY AREA-(FRA-)Nutzung der Datenbank überschreitet 90%.

Aktion: Konvertieren Sie den Snapshot mit dbaascli zurück in die physische Standbydatenbank:

dbaascli dataguard convertStandby --standbyType physical --dbname <dbname>

Problemanweisung: Die RECO-Datenträgergruppe des VM-Clusters oder die FAST RECOVERY AREA-(FRA-)Nutzung der Datenbank überschreitet 95%.

Aktion: Für die Standbydatenbank muss ein Roll Forward mit der SQL*PLUS-Anweisung RECOVER DATABASE FROM SERVICE ausgeführt werden.

dbaascli dataguard convertStandby --dbname <db name> --standbyType physical

Managed Recovery und Redo Transport stoppen

Stoppen Sie den Transport, und wenden Sie Redologs auf die Standby-Datenbank an.

DGMGRL> edit database <primary> set state=TRANSPORT-OFF;
DGMGRL> edit database <standby> set state=APPLY-OFF;

Vorhandene Logdateinamen speichern

Der Roll Forward-Prozess erstellt neue Online-Redo-Logs und Standby-Redo-Logs, wobei die vorhandenen Logs als Waisenkinder übrig bleiben, die Speicherplatz belegen. Verwenden Sie die folgende Abfrage, um die Namen dieser Logdateien zu speichern, damit sie später entfernt werden können.

SQL> set heading off linesize 999 pagesize 0 feedback off trimspool on
SQL> spool /tmp/delete_logfiles.log
SQL> select member from v$logfile;
SQL> spool off;

Aktuelle RMAN-Konfigurationseinstellungen speichern

Speichern Sie die RMAN-Konfiguration der Standby-Datenbank, damit sie nach dem Zurückschreiben der Kontrolldatei erneut angewendet werden kann.

$ rman target / nocatalog log=/tmp/RMAN_settings.log <<EOF
show all;
$ grep ^CONFIGURE /tmp/RMAN_settings.log | grep -v 'RETENTION POLICY' >/tmp/RMAN_settings.rman
$ rm /tmp/RMAN_settings.log

Standbykontrolldatei aus der Primärdatenbank aktualisieren

1. Bevor Sie Backups löschen, bestimmen Sie, ob AL-Backups, die von der Snapshot-Datenbank erstellt wurden, beibehalten werden müssen.
   • Bei OSS-, NAS- und Datenträgerbackups werden diese Backups nicht mehr von der Datenbank verfolgt und daher nicht in das aufbewahrungsbasierte Löschen einbezogen.
   • Solche Backups müssen manuell direkt aus ihrem Backupziel gelöscht werden, wenn sie nicht mehr benötigt werden.
2. Wenn Backups nicht mehr benötigt werden, können sie mit RMAN gelöscht werden. Dadurch wird zukünftig ein manuelles Löschen vermieden.

   RMAN> delete force noprompt backup device type 'sbt_tape';
   RMAN> delete force noprompt archivelog all device type 'sbt_tape';
   RMAN> delete force noprompt datafilecopy all device type 'sbt_tape';

3. Schreiben Sie die Kontrolldatei aus der primären Datenbank zurück.

   $ srvctl stop database -d <db> -o immediate
   $ rman target / nocatalog
   RMAN> startup nomount
   RMAN> restore standby controlfile from service <tns alias for primary database>;
   RMAN> alter database mount;

4. Ersetzen Sie die RMAN-Konfigurationseinstellungen, und entfernen Sie die verwaisten Online- und Standby Redo Log-Dateien.

   RMAN> @/tmp/RMAN_settings.rman
   <output from CONFIGURE commands in the script>
   RMAN> exit
   $ rm /tmp/RMAN_settings.rman

5. Schreiben Sie die Datendateien zurück:
   1. Wechseln Sie zur aktuellen Inkarnation der Primärdatenbank. Führen Sie in der primären Datenbank folgenden Befehl aus:

      RMAN> list incarnation;
      list incarnation;
      using target database control file instead of recovery catalog
       
      List of Database Incarnations
      DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
      ------- ------- -------- ---------------- --- ---------- ----------
      1       1       OGG_DG   1153531161       PARENT  1          21-JAN-25
      2       2       OGG_DG   1153531161       CURRENT 1514702    01-JUL-25
      

   2. Führen Sie in der Standby-Datenbank folgenden Befehl aus:

      RMAN> reset database to incarnation <>;

6. Roll Forward der Standbydatenbank: Die Standbydatenbank ist jetzt bereit, das inkrementelle Roll Forward mit dem Recovery-from-Service-Vorgang auszuführen.

   Starten Sie alle Instanzen neu, um sie zu mounten.

   $ srvctl stop database -db <dbname> -o immediate
   $ srvctl start database -db <dbname> -o mount
   

7. Redo Transport erneut aktivieren: Beim Roll Forward generierte archivierte Logs sind erforderlich, um die Datenbank in einen konsistenten Status zu versetzen. Es ist effizienter, der primären Datenbank zuzulassen, dass Redo an die Standbydatenbank gesendet wird, während das Roll Forward ausgeführt wird, anstatt darauf zu warten, dass die Logs nach Abschluss des Roll Forward übertragen werden.
   1. Prüfen Sie das Logarchivziel für diese Standbydatenbank, und notieren Sie sich die Zielnummer.

      SQL> show parameter LOG_ARCHIVE_DEST_;
      NAME                     TYPE    VALUE
      ------------------------------------ ----------- ------------------------------
      log_archive_dest_2  string  service="snby002", ASYNC NOAFF
                               IRM delay=0 optional compressi
                               on=disable max_failure=0 reope
                               n=300 db_unique_name="snby002"
                               net_timeout=30, valid_for=(on
                               line_logfile,all_roles)

   2. Aktivieren Sie Redo Transport.

      DGMGRL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

   3. Führen Sie diesen Vorgang mit Data Guard Broker entweder aus der Primär- oder der Standbydatenbank aus.

      DGMGRL> edit database <primary> set state=TRANSPORT-ON;

8. Recovery von Service ausführen: Der Recovery-Befehl kann alle verfügbaren Standbyinstanzen während des Recovery-Prozesses verwenden.

   $ rman target sys/<password>  <- It is necessary to connect with the password
   RMAN > run {
       
   allocate channel c1 type disk connect '/@<standby instance 1 SID_NAME>';
   allocate channel c2 type disk connect '/@<standby instance 1 SID_NAME>';
   allocate channel c3 type disk connect '/@<standby instance 1 SID_NAME>';
   allocate channel c4 type disk connect '/@<standby instance 1 SID_NAME>';
   allocate channel c5 type disk connect '/@<standby instance 2 SID_NAME>';
   allocate channel c6 type disk connect '/@<standby instance 2 SID_NAME>';
   allocate channel c7 type disk connect '/@<standby instance 2 SID_NAME>';
   allocate channel c8 type disk connect '/@<standby instance 2 SID_NAME>';
   restore database from service '<primary unique name>' section size 64G;
   recover database from service '<primary unique name>' section size 64G;
   }

9. Recovery bis zur Konsistenz: Nach Abschluss des Befehls RECOVER DATABASE FROM SERVICE ist ein zusätzliches Recovery erforderlich, um die Standbydatenbank konsistent zu machen, bevor Sie Flashback Database erneut aktivieren und im schreibgeschützten Modus öffnen können.

   Eine Datenbank gilt als konsistent, wenn die Kontrolldatei und alle Datendateien dieselbe SCN aufweisen. Die Höhe der zusätzlichen Wiederherstellung hängt davon ab, wie lange die anfängliche Wiederherstellung dauerte und wie hoch die Aktivität auf der primären in diesem Zeitraum war.

   Als ersten Schritt wechseln Sie ein Log in der primären Datenbank, um sicherzustellen, dass das letzte während des Recovery-Prozesses generierte Redo archiviert wird.

   Führen Sie in der primären Datenbank folgenden Befehl aus:

   SQL> alter system archive log current;

10. Flashback Database erneut aktivieren: Wenn Sie die Standby-Kontrolldatei wiederherstellen, wird Flashback Database automatisch deaktiviert. Nachdem die Standbydatenbank in einen konsistenten Status versetzt wurde, können Sie Flashback Database erneut aktivieren.

    SQL> alter database flashback on;

11. Starten Sie die Standbydatenbank neu, und aktivieren Sie das Managed Recovery erneut.

    $ srvctl stop database -db <dbname> -o immediate
    $ srvctl start database -db <dbname> -o 'read only'

12. Aktivieren Sie Redo Apply.

    DGMGRL> edit database <standby> set state=APPLY-ON;