Beheben von DB-Problemen für Amazon RDS Custom für Oracle - Amazon Relational Database Service
Anzeigen von benutzerdefinierten RDS-EreignissenAbonnieren von benutzerdefinierten RDS-EreignissenFehlerbehebung bei der CEV-ErstellungFehlerbehebung bei nicht unterstützten Konfigurationen in RDS Custom für OracleBehebung von RDS Custom für Oracle-Upgrade-Problembehandlung bei RDS Custom for Oracle

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Beheben von DB-Problemen für Amazon RDS Custom für Oracle

Das Modell der gemeinsamen Verantwortung von RDS Custom bietet Zugriff auf Betriebssystem-Shell-Ebene und Zugriff auf Datenbankadministratoren. RDS Custom führt Ressourcen in Ihrem Konto aus, im Gegensatz zu Amazon RDS, das Ressourcen in einem Systemkonto ausführt. Mit einem größeren Zugang kommt eine größere Verantwortung mit sich. In den folgenden Abschnitten können Sie lernen, wie Sie Probleme mit Amazon-RDS-Custom DB-Instances beheben können.

Anmerkung

In diesem Abschnitt wird die Fehlerbehebung für RDS Custom für Oracle beschrieben. Informationen zur Fehlerbehebung für RDS Custom für SQL Server finden Sie unter Beheben von DB-Problemen für Amazon RDS Custom for SDL Server.

Anzeigen von benutzerdefinierten RDS-Ereignissen

Das Verfahren zum Anzeigen von Ereignissen ist für RDS Custom- und Amazon RDS DB-Instances gleich. Weitere Informationen finden Sie unter Anzeigen von Amazon RDS-Ereignissen.

Verwenden Sie den describe-events Befehl AWS CLI, um die benutzerdefinierte RDS-Ereignisbenachrichtigung mit dem anzuzeigen. RDS Custom führt mehrere neue Ereignisse ein. Die Ereigniskategorien sind die gleichen wie für Amazon RDS. Eine Liste der Ereignisse finden Sie unter Amazon RDS-Ereigniskategorien und Ereignisnachrichten .

Im folgenden Beispiel werden Details zu den Ereignissen abgerufen, die für die angegebene RDS Custom DB-Instance aufgetreten sind.

aws rds describe-events \
    --source-identifier my-custom-instance \
    --source-type db-instance

Abonnieren von benutzerdefinierten RDS-Ereignissen

Das Verfahren zum Abonnieren von Ereignissen ist für RDS Custom- und Amazon RDS DB-Instances gleich. Weitere Informationen finden Sie unter Abonnieren von Amazon RDS-Ereignisbenachrichtigungen.

Verwenden Sie den Befehl create-event-subscription, um Ereignisbenachrichtigungen von RDS Custom zu abonnieren. Nutzen Sie die folgenden erforderlichen Parameter:

  • --subscription-name

  • --sns-topic-arn

Im folgenden Beispiel wird ein Abonnement für Backup- und Wiederherstellungsereignisse für eine RDS Custom DB-Instance im aktuellen AWS -Konto. Sie können auch anfordern, dass Benachrichtigungen an ein bestimmtes Amazon-SNS-Thema (Amazon Simple Notification Service) gesendet werden, die --sns-topic-arn bestimmt.

aws rds create-event-subscription \
    --subscription-name my-instance-events \
    --source-type db-instance \
    --event-categories '["backup","recovery"]' \
    --sns-topic-arn arn:aws:sns:us-east-1:123456789012:interesting-events

Fehlerbehebung bei der Erstellung von benutzerdefinierten Engine-Versionen für RDS Custom for Oracle

Wenn die CEV-Erstellung fehlschlägt, gibt es Probleme mit RDS Custom RDS-EVENT-0198mit der MitteilungCreation failed for custom engine version major-engine-version.cev_name und enthält Details über den Fehler. Zum Beispiel druckt das Ereignis fehlende Dateien.

Die Erstellung von CEV schlägt möglicherweise aufgrund der folgenden Probleme fehl:

  • Der Amazon S3 S3-Bucket, der Ihre Installationsdateien enthält, befindet sich nicht in derselben AWS Region wie Ihr CEV.

  • Wenn Sie die CEV-Erstellung in einem AWS-Region zum ersten Mal anfordern, erstellt RDS Custom einen S3-Bucket zum Speichern von benutzerdefinierten RDS-Ressourcen (wie CEV-Artefakten, AWS CloudTrail Protokollen und Transaktionsprotokollen).

    Die CEV-Erstellung schlägt fehl, wenn RDS Custom den S3-Bucket nicht erstellen kann. Entweder hat der Anrufer keine S3-Berechtigungen wie unter Schritt 5: Erteilen Sie Ihrem IAM-Benutzer oder Ihrer IAM-Rolle die erforderlichen Berechtigungen oder die Anzahl der S3-Buckets hat das Limit erreicht.

  • Der Anrufer hat keine Berechtigung, Dateien aus Ihrem S3-Bucket abzurufen, der die Installationsmediendateien enthält. Diese Berechtigungen sind unter Schritt 7: Hinzufügen der erforderlichen IAM-Berechtigungen beschrieben.

  • Ihre IAM-Richtlinie hat eine aws:SourceIp-Bedingung. Befolgen Sie unbedingt die Empfehlungen unter AWS verweigert Zugriff auf AWS basierend auf der Quell-IP im AWS Identity and Access Management -Benutzerhandbuch. Stellen Sie außerdem sicher, dass der Aufrufer über die S3-Berechtigungen verfügt, die unter Schritt 5: Erteilen Sie Ihrem IAM-Benutzer oder Ihrer IAM-Rolle die erforderlichen Berechtigungen beschrieben sind.

  • Die im CEV-Manifest aufgeführten Installationsmediendateien befinden sich nicht in Ihrem S3-Bucket.

  • Die SHA-256-Prüfsummen der Installationsdateien sind RDS Custom nicht bekannt.

    Vergewissern Sie sich, dass die SHA-256-Prüfsummen der bereitgestellten Dateien mit der SHA-256-Prüfsumme auf der Oracle-Website übereinstimmen. Wenn die Prüfsummen übereinstimmen, wenden Sie sich an AWS -Support und geben Sie den fehlgeschlagenen CEV-Namen, den Dateinamen und die Prüfsumme an.

  • Die OPatch-Version ist mit den Patch-Dateien nicht kompatibel. Möglicherweise wird die folgende Meldung angezeigt: OPatch is lower than minimum required version. Check that the version meets the requirements for all patches, and try again. Wenn Sie einen Oracle-Patch anwenden möchten, müssen Sie eine kompatible Version des OPatch-Dienstprogramms verwenden. Sie finden die erforderliche Version des OPatch-Dienstprogramms in der Readme-Datei für den Patch. Laden Sie das neueste OPatch-Dienstprogramm von „My Oracle Support“ herunter und versuchen Sie erneut, Ihre CEV zu erstellen.

  • Die im CEV-Manifest angegebenen Patches sind in der falschen Reihenfolge.

Sie können RDS-Ereignisse entweder auf der RDS-Konsole (wählen Sie im Navigationsbereich Ereignisse aus) oder mithilfe des describe-events AWS CLI Befehls anzeigen. Die Standardsitzungsdauer beträgt 60 Minuten. Wenn keine Ereignisse zurückgegeben werden, geben Sie eine längere Dauer an, wie im folgenden Beispiel gezeigt.

aws rds describe-events --duration 360

Derzeit ist der MediaImport Service, der Dateien aus Amazon S3 importiert, um CEVs zu erstellen, nicht integriert. AWS CloudTrail Wenn Sie also die Datenprotokollierung für Amazon RDS einschalten CloudTrail, werden Anrufe an den MediaImport Service, wie z. B. das CreateCustomDbEngineVersion Ereignis, nicht protokolliert.

Möglicherweise sehen Sie jedoch Aufrufe vom API-Gateway, das auf Ihren Amazon S3-Bucket zugreift. Diese Anrufe stammen vom MediaImport Service für das CreateCustomDbEngineVersion Ereignis.

Fehlerbehebung bei nicht unterstützten Konfigurationen in RDS Custom für Oracle

Im Modell der geteilten Verantwortung sind Sie dafür verantwortlich, Konfigurationsprobleme zu beheben, die Ihre DB-Instance von RDS Custom für Oracle in den Status unsupported-configuration versetzen. Wenn das Problem in der AWS Infrastruktur liegt, können Sie es mit der Konsole oder AWS CLI dem beheben. Wenn das Problem mit dem Betriebssystem oder der Datenbankkonfiguration besteht, können Sie sich beim Host anmelden, um es zu beheben.

Anmerkung

In diesem Abschnitt wird erläutert, wie Sie nicht unterstützte Konfigurationen in RDS Custom für Oracle beheben. Weitere Informationen zu RDS Custom für SQL Server finden Sie unter Korrigieren von nicht unterstützten Konfigurationen in RDS Custom for SQL Server.

In der folgenden Tabelle finden Sie Beschreibungen der Benachrichtigungen und Ereignisse, die der Support-Perimeter sendet, und Informationen dazu, wie Sie die Probleme beheben können. Diese Benachrichtigungen und der Support-Umfang können sich ändern. Hintergrundinformationen zum Support-Perimeter finden Sie unter Support-Perimeter in RDS Custom. Beschreibungen der Ereignisse finden Sie unter Amazon RDS-Ereigniskategorien und Ereignisnachrichten .

Ereignis-ID Konfiguration RDS-Ereignisnachricht Aktion

SP-O0000

Manuelle, nicht unterstützte Konfiguration

Der Status der benutzerdefinierten RDS-DB-Instance ist aus folgendem Grund auf [Nicht unterstützte Konfiguration] gesetzt.

Um dieses Problem zu beheben, erstellen Sie einen AWS Support Fall.
AWS Ressourcen (Infrastruktur)

SP-O1001

Amazon Elastic Block Store (Amazon EBS)-Volumes

Die folgenden EBS-Volumes wurden der EC2-Instance ec2_id hinzugefügt: volume_id. Um das Problem zu beheben, trennen Sie die angegebenen Volumes von der Instance.

RDS Custom erstellt neben dem Root-Volume, das aus dem Amazon Machine Image (AMI) erstellt wurde, zwei Typen von EBS-Volumes und ordnet sie der EC2-Instance zu:

  • Das Binärvolume, auf dem sich die Binärdateien der Datenbanksoftware befinden

  • Die Datenvolumes, auf denen sich die Datenbankdateien befinden

Wenn Sie Ihre DB-Instance erstellen, konfigurieren die von Ihnen angegebenen Speicherkonfigurationen die Datenvolumes.

Der Support-Umfang überwacht Folgendes:

  • Die ersten EBS-Volumes, die mit der DB-Instance erstellt wurden, sind weiterhin der Instance zugeordnet.

  • Die anfänglichen EBS-Volumes haben immer noch die gleichen Konfigurationen wie ursprünglich festgelegt: Speichertyp, Größe, bereitgestellte IOPS und Speicherdurchsatz.

  • An die DB-Instance sind keine zusätzlichen EBS-Volumes angehängt.

Verwenden Sie den folgenden CLI-Befehl, um den Volume-Typ der EBS-Volume-Details mit den Details der RDS Custom for Oracle-DB-Instance zu vergleichen: 

aws rds describe-db-instances \ 
    --db-instance-identifier db-instance-name | grep StorageType

SP-O1002

Amazon Elastic Block Store (Amazon EBS)-Volumes

Das EBS-Volume volume_id wurde von der EC2-Instance [ec2_id] getrennt. Sie können das ursprüngliche Volume nicht von dieser Instance trennen. Um das Problem zu beheben, fügen Sie volume_id erneut an ec2_id an.

RDS Custom erstellt neben dem Root-Volume, das aus dem Amazon Machine Image (AMI) erstellt wurde, zwei Typen von EBS-Volumes und ordnet sie der EC2-Instance zu:

  • Das Binärvolume, auf dem sich die Binärdateien der Datenbanksoftware befinden

  • Die Datenvolumes, auf denen sich die Datenbankdateien befinden

Wenn Sie Ihre DB-Instance erstellen, konfigurieren die von Ihnen angegebenen Speicherkonfigurationen die Datenvolumes.

Der Support-Umfang überwacht Folgendes:

  • Die ersten EBS-Volumes, die mit der DB-Instance erstellt wurden, sind weiterhin der Instance zugeordnet.

  • Die anfänglichen EBS-Volumes haben immer noch die gleichen Konfigurationen wie ursprünglich festgelegt: Speichertyp, Größe, bereitgestellte IOPS und Speicherdurchsatz.

  • An die DB-Instance sind keine zusätzlichen EBS-Volumes angehängt.

Verwenden Sie den folgenden CLI-Befehl, um den Volume-Typ der EBS-Volume-Details mit den Details der RDS Custom for Oracle-DB-Instance zu vergleichen: 

aws rds describe-db-instances \ 
    --db-instance-identifier db-instance-name | grep StorageType

SP-O1003

Amazon Elastic Block Store (Amazon EBS)-Volumes

Das ursprüngliche EBS-Volume volume_id, das der EC2-Instance ec2_id zugeordnet ist, wurde wie folgt geändert: Größe [X] auf [Y], Typ [N] auf [M] oder IOPS [J] auf [K]. Um das Problem zu beheben, machen Sie die Änderung rückgängig.

RDS Custom erstellt neben dem Root-Volume, das aus dem Amazon Machine Image (AMI) erstellt wurde, zwei Typen von EBS-Volumes und ordnet sie der EC2-Instance zu:

  • Das Binärvolume, auf dem sich die Binärdateien der Datenbanksoftware befinden

  • Die Datenvolumes, auf denen sich die Datenbankdateien befinden

Wenn Sie Ihre DB-Instance erstellen, konfigurieren die von Ihnen angegebenen Speicherkonfigurationen die Datenvolumes.

Der Support-Umfang überwacht Folgendes:

  • Die ersten EBS-Volumes, die mit der DB-Instance erstellt wurden, sind weiterhin der Instance zugeordnet.

  • Die anfänglichen EBS-Volumes haben immer noch die gleichen Konfigurationen wie ursprünglich festgelegt: Speichertyp, Größe, bereitgestellte IOPS und Speicherdurchsatz.

  • An die DB-Instance sind keine zusätzlichen EBS-Volumes angehängt.

Verwenden Sie den folgenden CLI-Befehl, um den Volume-Typ der EBS-Volume-Details mit den Details der RDS Custom for Oracle-DB-Instance zu vergleichen: 

aws rds describe-db-instances \ 
    --db-instance-identifier db-instance-name | grep StorageType

SP-O1004

Status der Amazon-EC2-Instance

Durch die automatische Wiederherstellung befand sich die EC2-Instance [ec2_id] in einem beeinträchtigten Zustand. Informationen zur Behebung des Problems finden Sie unter Behebung von Fehlern bei der Instanzwiederherstellung.

Um den Status einer DB-Instance zu überprüfen, verwenden Sie die Konsole oder führen Sie den folgenden AWS CLI Befehl aus:

aws rds describe-db-instances \ 
    --db-instance-identifier db-instance-name |grep DBInstanceStatus

SP-O1005

Attribute der Amazon-EC2-Instance

Die EC2-Instanz [ec2_id] wurde wie folgt geändert: Das Attribut [att1] wurde von [val-old] in [val-new] geändert, das Attribut [att2] wurde von [val-old] in [val-new] geändert. Um das Problem zu beheben, kehren Sie zum ursprünglichen Wert zurück.

SP-O1006

Status der Amazon-EC2-Instance

Die EC2-Instanz [ec2_id] wurde beendet oder kann nicht gefunden werden. Um das Problem zu beheben, löschen Sie die RDS Custom DB-Instance.

Der Support-Perimeter überwacht Benachrichtigungen zu Statusänderungen von EC2-Instanzen. Die EC2-Instance muss immer ausgeführt werden.

Um Ihre DB-Instance zu löschen

  1. Um den Status einer DB-Instance zu überprüfen, verwenden Sie die Konsole oder führen Sie den folgenden AWS CLI Befehl aus: 

    aws rds describe-db-instances \ 
    --db-instance-identifier db-instance-name |grep DBInstanceStatus

  2. Löschen Sie Ihre RDS Custom for Oracle DB-Instance.

SP-O1007

Status der Amazon-EC2-Instance

Die EC2-Instanz [ec2_id] wurde gestoppt. Um das Problem zu beheben, starten Sie die Instance.

Der Support-Perimeter überwacht Benachrichtigungen zu Statusänderungen von EC2-Instanzen. Die EC2-Instance muss immer ausgeführt werden.

Um Ihre DB-Instance neu zu starten

  1. Um den Status einer DB-Instance zu überprüfen, verwenden Sie die Konsole oder führen Sie den folgenden AWS CLI Befehl aus: 

    aws rds describe-db-instances \ 
    --db-instance-identifier db-instance-name |grep DBInstanceStatus

  2. Starten Sie Ihre DB-Instance.

  3. Stellen Sie die Binär- und Datenvolumen neu ein.
Betriebssystem

SP-O2001

Status des RDS-Custom-Agenten

Der RDS Custom Agent wird nicht auf der EC2-Instance [ec2_id] ausgeführt. Stellen Sie sicher, dass der Agent auf [ec2_id] läuft.

Bei RDS Custom für Oracle geht die DB-Instance außerhalb des Supportumfangs, wenn der RDS Custom Agent stoppt. Der Agent veröffentlicht die IamAlive Metrik CloudWatch alle 30 Sekunden auf Amazon. Ein Alarm wird ausgelöst, wenn die Metrik 30 Sekunden lang nicht veröffentlicht wurde. Der Support-Umfang überwacht auch alle 30 Minuten den Prozessstatus des RDS Custom Agents auf dem Host.

Um den RDS Custom Agent neu zu starten

  1. Melden Sie sich bei Ihrem Host an und stellen Sie sicher, dass der RDS-Custom-Agent ausgeführt wird.

  2. Führen Sie den folgenden Befehl aus, um den Status des Agenten zu ermitteln.

    service rdscustomagent status

  3. Verwenden Sie den folgenden Befehl, um den Agenten zu starten.

    service rdscustomagent start

Wenn der RDS Custom Agent wieder läuft, wird die IamAlive Metrik auf Amazon CloudWatch veröffentlicht und der Alarm wechselt in den OK Status. Dieser Switch informiert den Support-Umfang darüber, dass der Agent ausgeführt wird.

SP-O2002

AWS Systems Manager Status des Agenten (SSM-Agent)

Der Systems Manager Manager-Agent auf der EC2-Instance [ec2_id] ist nicht erreichbar. Stellen Sie sicher, dass Sie die Netzwerk-, Agenten- und IAM-Berechtigungen korrekt konfiguriert haben.

Der SSM-Agent muss immer ausgeführt werden. Der RDS Custom Agent ist dafür verantwortlich, sicherzustellen, dass der Systems Manager-Agent ausgeführt wird. Wenn der SSM-Agent beendet und anschließend neu gestartet wurde, veröffentlicht der RDS Custom Agent eine Metrik für. CloudWatch Der RDS Custom Agent hat einen Alarm für die Metrik, die ausgelöst werden soll, wenn in jeder der letzten drei Minuten ein Neustart stattgefunden hat. Der Support-Perimeter überwacht außerdem alle 30 Minuten den Prozessstatus des SSM-Agenten auf dem Host.

Weitere Informationen finden Sie unter Fehlerbehebung bei SSM-Agent.

SP-O2003

AWS Systems Manager Status des Agenten (SSM-Agent)

Der Systems Manager Manager-Agent auf der EC2-Instance [ec2_id] ist mehrfach abgestürzt. Weitere Informationen finden Sie in der Dokumentation zur Fehlerbehebung für den SSM-Agenten.

Weitere Informationen finden Sie unter Fehlerbehebung bei SSM-Agent.

SP-O 2004

Zeitzone des Betriebssystems

Die Zeitzone auf der EC2-Instance [ec2_id] wurde geändert. Um dieses Problem zu beheben, setzen Sie die Zeitzone auf die vorherige Einstellung von [] zurück. previous-time-zone Verwenden Sie dann eine RDS-Optionsgruppe, um die Zeitzone zu ändern.

Die RDS-Automatisierung hat festgestellt, dass die Zeitzone auf dem Host ohne Verwendung einer Optionsgruppe geändert wurde. Diese Änderung auf Hostebene kann zu Fehlern bei der RDS-Automatisierung führen, sodass die EC2-Instance in diesen Status versetzt wird. unsupported-configuration

Um die Zeitzoneneinstellung zu korrigieren

  1. Melden Sie sich bei Ihrem EC2-Host an und überprüfen Sie die Zeitzone des Betriebssystems wie folgt:

    timedatectl

  2. Pausieren Sie RDS Custom Automatisierung. Weitere Informationen finden Sie unter Pausieren und Fortsetzen Ihrer DB-Instance von RDS Custom.

  3. Stoppen Sie die DB-Instance.

  4. Macht die Änderung der Zeitzone auf dem Betriebssystem rückgängig.

  5. Starten Sie die &db;-Instance.

  6. Fortsetzen Sie RDS Custom Automatisierung fort

Ihre DB-Instance ist innerhalb von 30 Minuten verfügbar. Um zu verhindern, dass Sie sich in future außerhalb des Perimeters bewegen, ändern Sie Ihre Zeitzone über eine Optionsgruppe. Weitere Informationen finden Sie unter Oracle-Zeitzone.

SP-O 2005

sudo-Konfigurationen

Den Sudo-Konfigurationen auf der EC2-Instanz [ec2_id] fehlen die erforderlichen Berechtigungen. Um dieses Problem zu beheben, machen Sie die letzten Änderungen an den Sudo-Konfigurationen rückgängig.

Der Support-Umfang überwacht, dass bestimmte Betriebssystembenutzer bestimmte Befehle auf der Box ausführen dürfen. Es überwacht sudo-Konfigurationen gegen den unterstützten Status.

Wenn die sudo-Konfigurationen nicht unterstützt werden, versucht RDS Custom, sie wieder in den zuvor unterstützten Zustand zu überschreiben. Wenn dies erfolgreich ist, wird die folgende Benachrichtigung gesendet:

RDS Custom hat Ihre Konfiguration erfolgreich überschrieben.

Um Änderungen an den Sudo-Konfigurationen zu untersuchen

  1. Loggen Sie sich bei Ihrem Host ein.

  2. Führen Sie den folgenden Befehl aus.

    visudo -c -f /etc/sudoers.d/individual_sudo_files

  3. Ändern Sie die sudo Konfigurationen nach Bedarf.

Nachdem der Support-Perimeter festgestellt hat, dass die sudo Konfigurationen unterstützt werden, ist Ihre RDS Custom for Oracle DB-Instance innerhalb von 30 Minuten verfügbar.

SP-O 2006

Barrierefreiheit im S3-Bucket

RDS Custom Automation kann keine Dateien aus dem S3-Bucket auf die EC2-Instance [ec2_id] herunterladen. Überprüfen Sie Ihre Netzwerkkonfiguration und stellen Sie sicher, dass die Instance Verbindungen zu und von S3 zulässt.
Datenbank

SP-O3001

Verzögerungsziel für Datenbankarchiv

Der Parameter ARCHIVE_LAG_TARGET auf der EC2-Instanz [ec2_id] liegt außerhalb des empfohlenen Bereichs value_range. Um das Problem zu beheben, setzen Sie den Parameter auf einen Wert innerhalb von value_range.

Der Support-Perimeter überwacht den ARCHIVE_LAG_TARGET Datenbankparameter, um sicherzustellen, dass der letzte wiederherstellbare Zeitpunkt der DB-Instance innerhalb angemessener Grenzen liegt.

Um das Verzögerungsziel für archivierte Redo-Logs zu ändern

  1. Melden Sie sich bei Ihrem EC2-Host an

  2. Connect zu Ihrer RDS Custom for Oracle DB-Instance her

  3. Ändern Sie den ARCHIVE_LAG_TARGET Parameter auf einen Wert zwischen 60 und 7200. Verwenden Sie beispielsweise die folgende SQL-Anweisung.

    ALTER SYSTEM SET ARCHIVE_LAG_TARGET=300 SCOPE=BOTH;

Ihre DB-Instance ist innerhalb von 30 Minuten verfügbar.

SP-O3002

Oracle-Data-Guard-Rolle

Die Datenbankrolle [role_name] wird für Oracle Data Guard auf der EC2-Instance [ec2_id] nicht unterstützt. Um das Problem zu beheben, setzen Sie den Parameter DATABASE_ROLE entweder auf PRIMARY oder PHYSICAL STANDBY.

Der Support-Perimeter überwacht die aktuelle Datenbankrolle alle 15 Sekunden und sendet eine CloudWatch Benachrichtigung, wenn sich die Datenbankrolle geändert hat. Oracle Data Guard DATABASE_ROLE-Parameter muss entweder PRIMARY oder PHYSICAL STANDBY sein.

Um Ihre Oracle Data Guard-Datenbankrolle auf einen unterstützten Wert zurückzusetzen

  1. Überprüfen Sie die Oracle Data Guard-Rolle, indem Sie die folgende Anweisung ausführen:

    SELECT DATABASE_ROLE FROM V$DATABASE;

  2. Wenn Ihre DB-Instance eigenständig ist, verwenden Sie eine der folgenden Anweisungen, um sie wieder in die PRIMARY Rolle umzuwandeln:

    ALTER DATABASE COMMIT TO SWITCHOVER PRIMARY;
ALTER DATABASE ACTIVATE STANDBY DATABASE;

    Wenn es sich bei Ihrer DB-Instance um ein Replikat handelt, verwenden Sie die folgende Anweisung, um ihr wieder die PHYSICAL STANDBY Rolle zuzuweisen:

    ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Nachdem der Support-Perimeter feststellt, dass die Datenbankrolle unterstützt wird, wird die DB-Instance von RDS Custom für Oracle innerhalb von 15 Sekunden verfügbar.

SP-O3003

Datenbank-Zustand

Der SMON-Prozess der Oracle-Datenbank befindet sich in einem Zombie-Status. Um das Problem zu beheben, stellen Sie die Datenbank auf der EC2-Instance [ec2_id] manuell wieder her, öffnen Sie die Datenbank und erstellen Sie dann sofort eine Sicherungskopie. Wenn Sie weitere Hilfe benötigen, wenden Sie sich an. AWS Support

Der Support-Umfang überwacht den Status der DB-Instance. Es überwacht auch, wie viele Neustarts während der vorherigen Stunde und des vorherigen Tages stattgefunden haben. Sie werden benachrichtigt, wenn sich die Instanz in einem Zustand befindet, in dem sie noch existiert, aber Sie können nicht damit interagieren.

Damit der Support-Perimeter den Status Ihrer Instanz auswertet

  1. Melden Sie sich bei Ihrem Host an und ermitteln Sie den Datenbankstatus.

    ps -eo pid,state,command | grep smon

  2. Falls erforderlich, starten Sie Ihre DB-Instance neu. Wenn der Neustart fehlschlägt, fahren Sie mit dem nächsten Schritt fort.

  3. Falls erforderlich, starten Sie Ihren EC2-Host neu.

Nach dem Neustart Ihrer DB-Instance erkennt der RDS Custom Agent, dass Ihre DB-Instance nicht mehr reagiert. Anschließend wird der Support-Perimeter benachrichtigt, damit der Status der DB-Instance neu bewertet wird.

SP-O3004

Datenbank-Protokollmodus

Der Datenbank-Logmodus auf der EC2-Instance [ec2_id] wurde auf [value_b] geändert. Um das Problem zu beheben, setzen Sie den Protokollmodus auf [value_a].
Um den Protokollmodus Ihrer DB-Instance zu ändern ARCHIVELOG

  1. Melden Sie sich bei Ihrem EC2-Host an.

  2. Connect zu Ihrer Datenbank her und führen Sie die folgende Anweisung aus:

    SELECT LOG_MODE FROM V$DATABASE;

    Oder Sie können den folgenden Befehl in SQL*Plus ausführen:

    ARCHIVE LOG LIST

  3. Führen Sie den folgenden SQL*Plus-Befehl aus, um ein konsistentes Herunterfahren einzuleiten.

    SHUTDOWN IMMEDIATE

Der RDS Custom Agent startet Ihre DB-Instance automatisch neu und setzt den Protokollmodus auf. ARCHIVELOG Ihre DB-Instance ist innerhalb von 30 Minuten verfügbar.

SP-O3005

Oracle-Homepfad

Das Oracle-Standardverzeichnis auf der EC2-Instance [ec2_id] wurde in new_path geändert. Um das Problem zu beheben, setzen Sie die Einstellung auf old_path zurück.

SP-O3006

Eindeutiger Datenbankname

Der eindeutige Datenbankname auf der EC2-Instance [ec2_id] wurde in new_value geändert. Um das Problem zu beheben, setzen Sie den Namen auf old_value zurück.
Um den eindeutigen Datenbanknamen für Ihre DB-Instance zu ändern

  1. Melden Sie sich bei Ihrem EC2-Host an.

  2. Connect der Datenbank her und führen Sie die folgende Anweisung aus:

    SELECT DB_UNIQUE_NAME FROM V$DATABASE;

  3. Geben Sie mit dem Befehl den eindeutigen Namen der ursprünglichen Datenbank anALTER SYSTEM SET DB_UNIQUE_NAME.

  4. Führen Sie die folgende SQL-Anweisung aus, um ein konsistentes Herunterfahren einzuleiten.

    SHUTDOWN IMMEDIATE;

Der RDS Custom Agent startet Ihre DB-Instance automatisch neu und setzt den Protokollmodus aufARCHIVELOG. Ihre DB-Instance ist innerhalb von 30 Minuten verfügbar.

Fehlerbehebung bei Upgrades für RDS Custom for Oracle

Ihr Upgrade einer RDS Custom for Oracle-Instanz schlägt möglicherweise fehl. Im Folgenden finden Sie einige wichtige Techniken, Dateien und Befehle, die Sie bei Upgrades von RDS Custom DB für Oracle DB-Instances verwenden können:

  • Untersuchen Sie die Upgrade-Ausgabeprotokolldateien im /tmp-Verzeichnis auf Ihrer DB-Instance. Die Namen der Protokolle hängen von Ihrer DB-Engine-Version ab. Es können beispielsweise Protokolle angezeigt werden, die die Zeichenfolgen catupgrd oder catup enthalten.

  • Untersuchen Sie die Datei alert.log im Verzeichnis /rdsdbdata/log/trace.

  • Führen Sie folgenden grep-Befehl im root-Verzeichnis zur Verfolgung des Upgrade-Betriebssystemprozesses aus. Dieser Befehl zeigt an, wo die Protokolldateien geschrieben werden, und bestimmt den Status des Upgrade-Prozesses.

    ps -aux | grep upg

    Das folgende Beispiel zeigt die Beispielausgabe.

    root     18884  0.0  0.0 235428  8172 ?        S<   17:03   0:00 /usr/bin/sudo -u rdsdb /rdsdbbin/scripts/oracle-control ORCL op_apply_upgrade_sh RDS-UPGRADE/2.upgrade.sh
rdsdb    18886  0.0  0.0 153968 12164 ?        S<   17:03   0:00 /usr/bin/perl -T -w /rdsdbbin/scripts/oracle-control ORCL op_apply_upgrade_sh RDS-UPGRADE/2.upgrade.sh
rdsdb    18887  0.0  0.0 113196  3032 ?        S<   17:03   0:00 /bin/sh /rdsdbbin/oracle/rdbms/admin/RDS-UPGRADE/2.upgrade.sh
rdsdb    18900  0.0  0.0 113196  1812 ?        S<   17:03   0:00 /bin/sh /rdsdbbin/oracle/rdbms/admin/RDS-UPGRADE/2.upgrade.sh
rdsdb    18901  0.1  0.0 167652 20620 ?        S<   17:03   0:07 /rdsdbbin/oracle/perl/bin/perl catctl.pl -n 4 -d /rdsdbbin/oracle/rdbms/admin -l /tmp catupgrd.sql
root     29944  0.0  0.0 112724  2316 pts/0    S+   18:43   0:00 grep --color=auto upg

  • Führen Sie die folgende SQL-Abfrage aus, um den aktuellen Status der Komponenten zu überprüfen, um die Datenbankversion und die auf der DB-Instance installierten Optionen zu finden.

    SET LINESIZE 180
COLUMN COMP_ID FORMAT A15
COLUMN COMP_NAME FORMAT A40 TRUNC
COLUMN STATUS FORMAT A15 TRUNC
SELECT COMP_ID, COMP_NAME, VERSION, STATUS FROM DBA_REGISTRY ORDER BY 1;

    Die Ausgabe sieht in etwa folgendermaßen aus.

    COMP_NAME                                STATUS               PROCEDURE
---------------------------------------- -------------------- --------------------------------------------------
Oracle Database Catalog Views            VALID                DBMS_REGISTRY_SYS.VALIDATE_CATALOG
Oracle Database Packages and Types       VALID                DBMS_REGISTRY_SYS.VALIDATE_CATPROC
Oracle Text                              VALID                VALIDATE_CONTEXT
Oracle XML Database                      VALID                DBMS_REGXDB.VALIDATEXDB

4 rows selected.

  • Führen Sie die folgende SQL-Abfrage aus, um nach ungültigen Objekten zu suchen, die den Upgradeprozess beeinträchtigen könnten.

    SET PAGES 1000 LINES 2000
COL OBJECT FOR A40
SELECT SUBSTR(OWNER,1,12) OWNER,
       SUBSTR(OBJECT_NAME,1,30) OBJECT,
       SUBSTR(OBJECT_TYPE,1,30) TYPE, STATUS,
       CREATED
FROM   DBA_OBJECTS 
WHERE  STATUS <>'VALID' 
AND    OWNER IN ('SYS','SYSTEM','RDSADMIN','XDB');

Behebung von Fehlerbehebung bei der Heraufstufung von Replikaten für RDS

Sie können verwaltete Oracle-Repliken in RDS Custom for Oracle mithilfe der Konsole, des promote-read-replica AWS CLI Befehls oder PromoteReadReplica der API hochstufen. Wenn Sie Ihre primäre DB-Instance löschen und alle Replikate fehlerfrei sind, stuft RDS Custom for Oracle Ihre verwalteten Replikate automatisch zu eigenständigen Instances herauf. Wenn ein Replikat die Automatisierung unterbrochen hat oder sich außerhalb des Supportumfangs befindet, müssen Sie das Replikat reparieren, bevor RDS Custom es automatisch heraufstufen kann. Weitere Informationen finden Sie unter Einschränkungen beim Hochstufen von Replikaten von RDS Custom für Oracle.

Der Workflow zur Replikat-Heraufstufung kann in der folgenden Situation hängen bleiben:

  • Die primäre DB-Instance hat den Status STORAGE_FULL.

  • Die Primärdatenbank kann nicht alle ihre Online-Redo-Logs archivieren.

  • Zwischen den archivierten Redo-Log-Dateien auf dem Oracle-Replikat und der Primärdatenbank besteht eine Lücke.

Um auf den festgefahrenen Workflow zu reagieren

  1. Synchronisieren Sie die Redo-Log-Lücke auf Ihrer Oracle Replica DB-Instance.

  2. Erzwingen Sie die Heraufstufung Ihres gelesenen Replikats auf das neueste angewandte Redo-Protokoll. Führen Sie die folgenden Befehle in SQL*Plus aus:

    ALTER DATABASE ACTIVATE STANDBY DATABASE;
SHUTDOWN IMMEDIATE
STARTUP

  3. Kontaktieren Sie sie AWS Support und bitten Sie sie, Ihre DB-Instance in available den Status zu versetzen.