Behebung von DB-Problemen für Amazon RDS Custom for Oracle - Amazon Relational Database Service
RDSBenutzerdefinierte Ereignisse anzeigenBenutzerdefinierte Ereignisse abonnieren RDSProblembehandlung bei CEV der ErstellungBehebung nicht unterstützter Konfigurationen in RDS Custom for OracleBehebung von Problemen mit dem Upgrade von RDS Custom for OracleProblembehandlung bei RDS Custom for Oracle Replica Promotion

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.

Behebung von DB-Problemen für Amazon RDS Custom for Oracle

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

Anmerkung

In diesem Abschnitt wird erklärt, wie Sie RDS Custom for Oracle beheben können. Informationen zur Fehlerbehebung bei RDS Custom for SQL Server finden Sie unterBeheben von DB-Problemen für Amazon RDS Custom for SDL Server.

RDSBenutzerdefinierte Ereignisse anzeigen

Das Verfahren zum Anzeigen von Ereignissen ist für RDS benutzerdefinierte und RDS Amazon-DB-Instances identisch. Weitere Informationen finden Sie unter RDSAmazon-Ereignisse anzeigen.

Verwenden Sie den describe-events Befehl AWS CLI, um RDS benutzerdefinierte Ereignisbenachrichtigungen mit dem anzuzeigen. RDS Custom führt mehrere neue Ereignisse ein. Die Veranstaltungskategorien sind dieselben wie bei AmazonRDS. 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 benutzerdefinierte DB-Instance aufgetreten sind.

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

Benutzerdefinierte Ereignisse abonnieren RDS

Das Verfahren zum Abonnieren von Ereignissen ist für RDS benutzerdefinierte DB-Instances und RDS Amazon-DB-Instances identisch. Weitere Informationen finden Sie unter RDSAmazon-Veranstaltungsbenachrichtigung abonnieren.

Verwenden Sie den create-event-subscription Befehl, um RDS benutzerdefinierte Ereignisbenachrichtigungen mit dem CLI zu abonnieren. Nutzen Sie die folgenden erforderlichen Parameter:

  • --subscription-name

  • --sns-topic-arn

Im folgenden Beispiel wird ein Abonnement für Sicherungs- und Wiederherstellungsereignisse für eine RDS benutzerdefinierte DB-Instance im aktuellen AWS Konto erstellt. Benachrichtigungen werden an ein Amazon Simple Notification Service (AmazonSNS) -Thema gesendet, das von spezifiziert ist--sns-topic-arn.

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

Problembehandlung bei der Erstellung einer benutzerdefinierten Engine-Version für RDS Custom for Oracle

Wenn die CEV Erstellung fehlschlägt, gibt RDS Custom einen Fehler RDS-EVENT-0198 mit der Nachricht Creation failed for custom engine version major-engine-version.cev_name aus und enthält Informationen zum Fehler. Zum Beispiel druckt das Ereignis fehlende Dateien.

CEVDie Erstellung 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 IhrCEV.

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

    CEVDie 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: Fügen Sie die erforderlichen IAM Berechtigungen hinzu beschrieben.

  • Ihre IAM Richtlinie ist an eine aws:SourceIp Bedingung geknüpft. 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 Custom unbekannt. RDS

    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 den AWS Support und geben Sie den CEV Namen, den Dateinamen und die Prüfsumme des Fehlers an.

  • Die OPatch Version ist nicht mit Ihren Patch-Dateien 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. Um einen Oracle-Patch anzuwenden, 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 Programm von My Oracle Support herunter, und versuchen Sie CEV erneut, Ihr Programm zu erstellen.

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

Sie können RDS Ereignisse entweder in 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 sie zu erstellen, CEVs nicht integriert AWS CloudTrail. Wenn Sie also die Datenprotokollierung für Amazon RDS in aktivieren CloudTrail, werden Anrufe an den MediaImport Service, wie z. B. das CreateCustomDbEngineVersion Ereignis, nicht protokolliert.

Möglicherweise sehen Sie jedoch Anrufe von dem API Gateway, das auf Ihren Amazon S3 S3-Bucket zugreift. Diese Anrufe kommen vom MediaImport Service für die CreateCustomDbEngineVersion Veranstaltung.

Behebung nicht unterstützter Konfigurationen in RDS Custom for Oracle

Im Modell der geteilten Verantwortung liegt es in Ihrer Verantwortung, Konfigurationsprobleme zu beheben, die Ihre RDS Custom for Oracle-DB-Instance in den falschen unsupported-configuration Zustand versetzt haben. Wenn das Problem in der AWS Infrastruktur liegt, verwenden Sie die Konsole oder die, AWS CLI um es zu beheben. Wenn das Problem mit dem Betriebssystem oder der Datenbankkonfiguration zusammenhängt, melden Sie sich beim Host an, um das Problem zu beheben.

Anmerkung

In diesem Abschnitt wird erklärt, wie Sie nicht unterstützte Konfigurationen in RDS Custom for Oracle beheben können. Informationen zu RDS Custom for SQL Server finden Sie unterKorrigieren von nicht unterstützten Konfigurationen in RDS Custom for SQL Server.

Die folgende Tabelle enthält eine Beschreibung der Benachrichtigungen und Ereignisse, die vom Support-Perimeter gesendet werden, und zeigt, wie diese behoben werden 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 RDSEreignisnachricht Aktion

SP-O0000

Manuelle, nicht unterstützte Konfiguration

Der Status der RDS benutzerdefinierten DB-Instance ist aus folgenden Gründen auf [Nicht unterstützte Konfiguration] gesetzt:. reason

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

SP-O1001

Volumen im Amazon Elastic Block Store (AmazonEBS)

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

RDSCustom erstellt neben dem EBS Root-Volume, das aus dem Amazon Machine Image (AMI) erstellt wurde, zwei Arten von 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 anfänglichen EBS Volumes, die mit der DB-Instance erstellt wurden, sind weiterhin der Instance zugeordnet.

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

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

Verwenden Sie den folgenden CLI Befehl, um den Volume-Typ der Volume-Details mit den EBS 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

Volumen im Amazon Elastic Block Store (AmazonEBS)

EBSDas Volume volume_id wurde von der EC2 Instance [ec2_id] getrennt. Sie können das ursprüngliche Volume nicht von dieser Instanz trennen. Um das Problem zu beheben, stellen Sie erneut volume_id eine Verbindung zu her. ec2_id

RDSCustom erstellt neben dem EBS Root-Volume, das aus dem Amazon Machine Image (AMI) erstellt wurde, zwei Arten von 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 anfänglichen EBS Volumes, die mit der DB-Instance erstellt wurden, sind weiterhin der Instance zugeordnet.

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

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

Verwenden Sie den folgenden CLI Befehl, um den Volume-Typ der Volume-Details mit den EBS 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

Volumen im Amazon Elastic Block Store (AmazonEBS)

Das der EC2 Instance volume_id zugeordnete ursprüngliche EBS Volume ec2_id 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.

RDSCustom erstellt neben dem EBS Root-Volume, das aus dem Amazon Machine Image (AMI) erstellt wurde, zwei Arten von 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 anfänglichen EBS Volumes, die mit der DB-Instance erstellt wurden, sind weiterhin der Instance zugeordnet.

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

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

Verwenden Sie den folgenden CLI Befehl, um den Volume-Typ der Volume-Details mit den EBS 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 EC2 Amazon-Instanz

Bei der automatisierten 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

EC2Amazon-Instance-Attribute

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

SP-O1006

Status der EC2 Amazon-Instanz

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

Der Support-Perimeter überwacht Benachrichtigungen über Statusänderungen der EC2 Instance. Die EC2 Instanz muss immer laufen.

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 EC2 Amazon-Instanz

EC2Instanz [ec2_id] wurde gestoppt. Um das Problem zu beheben, starten Sie die Instanz.

Der Support-Perimeter überwacht Benachrichtigungen über Statusänderungen der EC2 Instanz. Die EC2 Instanz muss immer laufen.

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

RDSBenutzerdefinierter Agentenstatus

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

Bei RDS Custom for Oracle verlässt die DB-Instance den Support-Perimeter, wenn der RDS Custom Agent beendet wird. 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-Perimeter überwacht außerdem 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 läuft.

  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 SSM Agenten (Agenten)

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

SSMDer Agent muss immer ausgeführt werden. Der RDS benutzerdefinierte Agent ist dafür verantwortlich, sicherzustellen, dass der Systems Manager Manager-Agent ausgeführt wird. Wenn der SSM Agent beendet und anschließend neu gestartet wurde, veröffentlicht der RDS benutzerdefinierte Agent eine Metrik für CloudWatch. Der RDS benutzerdefinierte Agent hat einen Alarm für die Metrik eingerichtet, der ausgelöst wird, wenn in den letzten drei Minuten jeweils 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 Troubleshooting SSM Agent.

SP-O2003

AWS Systems Manager Status des SSM Agenten (Agenten)

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

Weitere Informationen finden Sie unter Troubleshooting SSM Agent.

SP-O 2004

Zeitzone des Betriebssystems

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

RDSDie Automatisierung hat festgestellt, dass die Zeitzone auf dem Host ohne Verwendung einer Optionsgruppe geändert wurde. Diese Änderung auf Hostebene kann zu RDS Automatisierungsfehlern führen, sodass die EC2 Instanz in den unsupported-configuration Status versetzt wird.

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. Unterbrechen Sie die RDS benutzerdefinierte Automatisierung. Weitere Informationen finden Sie unter Ihre benutzerdefinierte DB-Instance pausieren und wieder aufnehmen RDS.

  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. Setzen Sie die RDS benutzerdefinierte 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 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-Perimeter überprüft, ob bestimmte Betriebssystembenutzer bestimmte Befehle auf dem Host ausführen dürfen. Es überwacht sudo Konfigurationen und vergleicht sie mit dem unterstützten Status.

Wenn die sudo Konfigurationen nicht unterstützt werden, versucht RDS Custom, sie zu überschreiben und zum vorherigen unterstützten Status zurückzukehren. Wenn der Versuch erfolgreich ist, sendet RDS Custom die folgende Benachrichtigung:

RDSCustom hat Ihre Konfiguration erfolgreich überschrieben.

Wenn das Überschreiben nicht erfolgreich ist, verbleibt Ihre DB-Instance im Konfigurationsstatus „Nicht unterstützt“. Um dieses Problem zu beheben, machen Sie entweder die Änderungen in der sudoers.d/ Datei rückgängig oder korrigieren Sie die Berechtigungen.

Um Änderungen an den Konfigurationen zu untersuchen sudo

  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

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

SP-O3001

Verzögerungsziel für Datenbankarchiv

Der TARGET Parameter ARCHIVE _ LAG _ für 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. Loggen Sie sich bei Ihrem EC2 Host ein

  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 Anweisung. SQL

    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 EC2 Instance [] nicht unterstützt. ec2_id Um das Problem zu beheben, setzen Sie den ROLE Parameter DATABASE _ entweder auf PRIMARY oder PHYSICALSTANDBY.

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 festgestellt hat, dass die Datenbankrolle unterstützt wird, ist Ihre RDS Custom for Oracle-DB-Instance 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 EC2 Instanz [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 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 Datenbankprotokollmodus auf EC2 Instanz [ec2_id] wurde auf [] geändert. value_b 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 SQL in*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 EC2 Instanz [ec2_id] wurde geändert innew_path. Um das Problem zu beheben, setzen Sie die Einstellung auf zurückold_path.

SP-O3006

Eindeutiger Datenbankname

Der eindeutige Datenbankname auf EC2 Instanz [ec2_id] wurde geändert innew_value. Um das Problem zu beheben, setzen Sie den Namen auf zurückold_value.
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 Techniken, die Sie bei Upgrades von RDS Custom DB for 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 und die Datenbankversion und die auf der DB-Instance installierten Optionen zu ermitteln.

    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 Upgrade-Prozess stören 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');

Problembehandlung bei der Replikat-Promotion für RDS Custom for Oracle

Sie können verwaltete Oracle-Replicas in RDS Custom for Oracle mithilfe der Konsole, des promote-read-replica AWS CLI Befehls oder heraufstufen. PromoteReadReplica API 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 angehalten hat oder sich außerhalb des Support-Bereichs befindet, müssen Sie das Replikat reparieren, bevor Custom es automatisch heraufstufen kann. RDS Weitere Informationen finden Sie unter Heraufstufen eines RDS Custom for Oracle-Replikats zu einer eigenständigen DB-Instance.

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 SQL in*Plus aus:

    ALTER DATABASE ACTIVATE STANDBY DATABASE;
SHUTDOWN IMMEDIATE
STARTUP

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