Upgraden der Oracle-DB-Engine - Amazon Relational Database Service
Übersicht über Oracle-UpgradesHauptversions-UpgradesUnterversion-UpgradesSE2-Upgrade-PfadeÜberlegungen zum UpgradeTesten eines UpgradesAutomatisches 11g SE1-UpgradeUpgraden einer Oracle-DB-Instance

Upgraden der Oracle-DB-Engine

Wenn Amazon RDS eine neue Version von Oracle unterstützt, können Sie Ihre DB-Instances auf die neue Version upgraden. Amazon RDS unterstützt die folgenden Upgrades für eine Oracle-DB-Instance:

  • Hauptversions-Upgrades

    Im Allgemeinen kann ein Upgrade der Hauptversion für ein Datenbank-Engine Änderungen einführen, die nicht mit vorhandenen Anwendungen kompatibel sind. Sie müssen die DB-Instance manuell ändern, um ein Hauptversions-Upgrade durchführen zu können.

    Wichtig

    Am 01. November 2020 beginnt Amazon RDS automatisch mit dem Upgrade von Oracle 11g SE1 License Included (LI)-Instances auf Oracle 19c. Durch das automatische Upgrade werden alle 11g DB-Instances auf das neueste verfügbare Oracle Release Update verschoben. Weitere Informationen finden Sie unter Vorbereiten des automatischen Oracle 11g SE1-Upgrades.

  • Nebenversion-Upgrades

    Ein Nebenversion-Upgrade enthalten nur Änderungen, die abwärtskompatibel mit bestehenden Anwendungen sind. Unterversion-Upgrades erfolgen automatisch, wenn Sie automatische Unterversion-Upgrades für Ihre DB-Instance aktivieren. In allen anderen Fällen müssen Sie die DB-Instance manuell ändern.

Wenn Sie die DB-Engine aktualisieren, tritt ein Ausfall auf. Die Zeit für den Ausfall hängt von Ihrer Engine-Version und der Größe der Instance ab.

Weitere Informationen zu unterstützten Oracle-Versionen in Amazon RDS finden Sie unter Versionshinweise zur Oracle-Datenbank-Engine.

Übersicht über Oracle DB Engine-Upgrades

Wenn der Aufbewahrungszeitraum für Sicherungen für Ihre DB-Instance größer als 0 ist, erstellt Amazon RDS während des Upgrades die folgenden DB-Snapshots:

  1. Einen Snapshot der DB-Instance, bevor Upgrade-Änderungen vorgenommen wurden. Wenn das Upgrade bei Ihren Datenbanken nicht funktioniert, können Sie diesen Snapshot wiederherstellen, um eine DB-Instance zu erstellen, auf der die alte Version ausgeführt wird.

  2. Einen Snapshot der DB-Instance nach Abschluss des Upgrades.

Anmerkung

Informationen über das Ändern Ihres Aufbewahrungszeitraums für Backups finden Sie unter Ändern einer Amazon RDS-DB-Instance.

Nach Abschluss eines Upgrades können Sie nicht zur vorherigen Version des DB-Moduls zurückkehren. Sie erstellen jedoch eine neue DB-Instance, indem Sie den DB-Snapshot wiederherstellen, der vor dem Upgrade erstellt wurde.

Oracle-Upgrades in einer Multi-AZ-Bereitstellung

Wenn sich Ihre DB-Instance in einer Multi-AZ-Bereitstellung befindet, werden sowohl die Primär- als auch die Standby-Replikate von Amazon RDS aktualisiert. Wenn keine Betriebssystemaktualisierungen erforderlich sind, werden die primären und Standby-Upgrades gleichzeitig durchgeführt. Die Instances sind erst verfügbar, wenn das Upgrade abgeschlossen ist.

Wenn Betriebssystemaktualisierungen in einer Multi-AZ-Bereitstellung erforderlich sind, wendet Amazon RDS die Updates an, wenn Sie das DB-Upgrade anfordern. Amazon RDS führt die folgenden Schritte aus:

  1. Aktualisieren Sie das Betriebssystem auf der Standby-DB-Instance.

  2. Aktualisieren Sie die Standby-DB-Instance.

  3. Failover der primären Instance zur Standby-DB-Instance.

  4. Aktualisieren Sie das Betriebssystem auf der neuen Standby-DB-Instance, die früher die primäre Instance war.

  5. Aktualisieren Sie die neue Standby-DB-Instance.

Oracle-Upgrades von Read Replicas (Lesereplikaten)

Die Oracle DB-Engine-Version der Quell-DB-Instance und alle Read Replica müssen identisch sein. Amazon RDS führt das Upgrade in den folgenden Phasen durch:

  1. Aktualisieren der Quell-DB-Instance. Die Read Replica sind in dieser Phase verfügbar.

  2. Paralleles Aktualisieren der Read Replica unabhängig von den Replikatwartungsfenstern. Die Quell-DB ist in dieser Phase verfügbar.

Bei Upgrades von regionsübergreifenden Read Replica führt Amazon RDS zusätzliche Aktionen durch:

  • Automatisches Generieren einer Optionsgruppe für die Zielversion

  • Kopieren aller Optionen und Optionseinstellungen aus der ursprünglichen Optionsgruppe in die neue Optionsgruppe

  • Verknüpfen des aktualisierten regionsübergreifenden Lese-Replikats mit der neuen Optionsgruppe

Oracle-Upgrades von Micro DB-Instances

Es wird nicht empfohlen, Datenbanken zu aktualisieren, die auf Micro-DB-Instances ausgeführt werden. Da diese Instances über eine begrenzte CPU-Leistung verfügen, kann das Upgrade Stunden dauern.

Sie können Micro-DB-Instances mit kleinen Speichermengen (10–20 GiB) aktualisieren, indem Sie Ihre Daten mit Data Pump kopieren. Bevor Sie Ihre Produktions-DB-Instances migrieren, sollten Sie testen, indem Sie Daten mithilfe von Data Pump kopieren.

Hauptversions-Upgrades

Amazon RDS unterstützt die folgenden Major-Versionsupgrades.

Sie müssen die DB-Instance manuell ändern, um ein Hauptversions-Upgrade durchführen zu können. Hauptversions-Upgrades werden nicht automatisch durchgeführt.

Unterstützte Versionen für Hauptversion-Upgrades

Amazon RDS unterstützt die folgenden Major-Versionsupgrades.

Aktuelle Version Unterstütztes Upgrade

18.0.0.0

19.0.0.0

12.2.0.1

19.0.0.0

18.0.0.0

12.1.0.2

19.0.0.0

18.0.0.0

12.2.0.1

11.2.0.4

19.0.0.0

18.0.0.0

12.2.0.1

12.1.0.2.v5 und höhere 12.1-Versionen

Hauptversions-Upgrades werden nicht für veraltete Oracle-Versionen, wie Oracle Version 11.2.0.3 oder 11.2.0.2 unterstützt. Herabstufungen der Hauptversion werden für Oracle-Versionen nicht unterstützt.

Für ein Upgrade der Hauptversion von 11g auf 12c muss ein Oracle Patch Set Update (PSU) ausgeführt werden, das im selben Monat oder später veröffentlicht wurde. Beispielsweise wird ein Upgrade der Hauptversion von 11.2.0.4.v14 auf 12.1.0.2.v11 unterstützt. Ein Upgrade der Hauptversion von 11.2.0.4.v14 auf 12.1.0.2.v9 wird jedoch nicht unterstützt. Der Grund hierfür liegt darin, dass Oracle Version 11.2.0.4.v14 im Oktober 2017 und Oracle Version 12.1.0.2.v9 im Juli 2017 erschienen ist. Weitere Informationen zu den Veröffentlichungsterminen der einzelnen Oracle PSUs erhalten Sie unter Versionshinweise zur Oracle-Datenbank-Engine.

Unterstützte Instance-Klassen für Hauptversion-Upgrades

In einigen Fällen wird Ihre aktuelle Oracle-DB-Instance möglicherweise auf einer DB-Instance-Klasse ausgeführt, die für die Version, auf die upgegradet werden soll, nicht unterstützt wird. Stellen Sie in einem solchen Fall sicher, dass Sie die DB-Instance vor dem Upgrade zu einer unterstützten DB-Instance-Klasse migrieren. Weitere Informationen über die unterstützten DB-Instance-Klassen für alle Versionen und Editionen von Amazon RDS Oracle finden Sie unter DB-Instance-Klassen.

Erfassen von Statistiken vor Hauptversion-Upgrades

Vor dem Ausführen eines Hauptversions-Upgrades empfiehlt Oracle, dass Sie für die zu aktualisierende DB-Instance eine Optimierungsstatistik erheben. Durch das Erheben von Optimierungsstatistiken kann die Ausfallzeit einer DB-Instance während des Upgrades reduziert werden.

Zum Erheben von Optimierungsstatistiken stellen Sie als Hauptbenutzer eine Verbindung zur DB-Instance her und führen die DBMS_STATS.GATHER_DICTIONARY_STATS-Prozedur durch. Vgl. hierzu das folgende Beispiel. 

EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

Weitere Informationen finden Sie unter Erfassen von Optimierungsstatistiken zur Reduzierung der Ausfallzeit der Oracle-Datenbank in der Oracle-Dokumentation.

Zulassen von Hauptversion-Upgrades

Ein Upgrade der Haupt-Engine-Version ist möglicherweise nicht mit Ihrer Anwendung kompatibel. Das Upgrade ist irreversibel. Wenn Sie eine Hauptversion für den Parameter „EngineVersion“ angeben, die sich von der aktuellen Hauptversion unterscheidet, müssen Sie Upgrades der Hauptversion zulassen.

Wenn Sie eine Hauptversion mit dem CLI-Befehl modify-db-instance aktualisieren, müssen Sie --allow-major-version-upgrade angeben. Bei dieser Berechtigung handelt es sich nicht um eine persistente Einstellung. Sie müssen daher --allow-major-version-upgrade angeben, wenn Sie ein wichtiges Upgrade durchführen. Dieser Parameter hat keine Auswirkungen auf Upgrades kleinerer Engine-Versionen. Weitere Informationen finden Sie unter Upgrade der Engine-Version für eine DB-Instance .

Wenn Sie eine Hauptversion mit der Konsole aktualisieren, müssen Sie keine Option zum Zulassen des Upgrades auswählen. Stattdessen zeigt die Konsole eine Warnung an, dass wichtige Upgrades irreversibel sind.

Oracle-Unterversion-Upgrades

Bei einem Upgrade einer Unterversion wird ein Oracle Database Patch Set Update (PSU) oder ein Release Update (RU) auf einer Hauptversion installiert.

Amazon RDS für Oracle-DB-Instances wird automatisch zeitplangesteuert im nächsten Wartungsfenster aktualisiert, wenn folgende Bedingungen zutreffen:

  • Für die DB-Instance ist die Option Auto Minor Version Upgrade (Automatisches Unterversions-Upgrade) aktiviert.

  • Die DB-Instance führt nicht die neueste DB-Engine-Unterversion aus.

Die DB-Instance wird vier bis sechs Wochen nach dem Erscheinungsdatum der neuesten Quartals-PSU oder -RU durch Amazon RDS für Oracle aktualisiert. Weitere Informationen zu PSUs und RUs finden Sie unter Versionshinweise zur Oracle-Datenbank-Engine.

Die folgenden Unterversions-Upgrades werden nicht unterstützt.

Aktuelle Version Nicht unterstütztes Upgrade

12.1.0.2.v6

12.1.0.2.v7

12.1.0.2.v5

12.1.0.2.v7

12.1.0.2.v5

12.1.0.2.v6
Anmerkung

Unterversions-Downgrades werden nicht unterstützt.

Oracle SE2-Upgrade-Pfade

In der folgenden Tabelle sind die unterstützten Upgrade-Pfade für Standard Edition Two (SE2) aufgeführt. Weitere Informationen zu Modellen "Lizenz enthalten" und "Verwendung der eigenen Lizenz" (BYOL) finden Sie unter Oracle-Lizenzierungsoptionen.

Ihre bestehende Konfiguration Unterstützte SE2-Konfiguration

12.2.0.1 SE2, Verwendung der eigenen Lizenz

12.2.0.1 SE2, Verwendung der eigenen Lizenz oder Lizenz enthalten

12.1.0.2 SE2, Verwendung der eigenen Lizenz

12.2.0.1 SE2, Verwendung der eigenen Lizenz oder Lizenz enthalten

12.1.0.2 SE2, Verwendung der eigenen Lizenz oder Lizenz enthalten

11.2.0.4 SE1, Verwendung der eigenen Lizenz oder enthaltene Lizenz

11.2.0.4 SE, Verwendung der eigenen Lizenz

12.2.0.1 SE2, Verwendung der eigenen Lizenz oder Lizenz enthalten

12.1.0.2 SE2, Verwendung der eigenen Lizenz oder Lizenz enthalten

Verwenden Sie einen unterstützten Upgrade-Pfad, um ein Upgrade Ihrer vorhandenen Konfiguration auf eine unterstützte SE2-Konfiguration vorzunehmen. Weitere Informationen finden Sie unter Hauptversions-Upgrades.

Überlegungen zu Oracle DB-Upgrades

Überprüfen Sie vor dem Upgrade die Auswirkungen auf Optionsgruppen, Parametergruppen und Zeitzonen.

Überlegungen zu Optionsgruppen

Wenn Ihre DB-Instance eine benutzerdefinierte Optionsgruppe verwendet, kann Amazon RDS in einigen Fällen Ihre DB-Instance nicht automatisch einer neuen Optionsgruppe zuweisen. Dies geschieht z.°B. beim Upgrade auf eine neue Hauptversion. In solchen Fällen müssen Sie eine neue Optionsgruppe angeben, wenn Sie ein Upgrade durchführen. Wir empfehlen, dass Sie eine neue Optionsgruppe erstellen und dieser dieselben Optionen hinzufügen, über die auch Ihre bestehende benutzerdefinierte Optionsgruppe verfügt.

Weitere Informationen finden Sie unter Erstellen einer Optionsgruppe oder Kopieren einer Optionsgruppe.

Wenn Ihre DB-Instance eine benutzerdefinierte Optionsgruppe mit der APEX-Option verwendet, können Sie in einigen Fällen die Dauer des Upgrades Ihrer DB-Instance verkürzen. Führen Sie dazu gleichzeitig ein Upgrade Ihrer APEX-Version und Ihrer DB-Instance durch. Weitere Informationen finden Sie unter Aktualisieren der APEX-Version.

Überlegungen zu Parametergruppen

Wenn Ihre DB-Instance eine benutzerdefinierte Parametergruppe verwendet, kann Amazon RDS zuweilen Ihre DB-Instance nicht automatisch einer neuen Parametergruppe zuweisen. Dies geschieht z.°B. beim Upgrade auf eine neue Hauptversion. Stellen Sie in diesen Fällen sicher, dass Sie beim Upgrade eine neue Parametergruppe angeben. Wir empfehlen, dass Sie eine neue Parametergruppe erstellen und die Parameter so konfigurieren wie in Ihrer bestehenden benutzerdefinierten Parametergruppe.

Weitere Informationen finden Sie unter Erstellen einer DB-Parametergruppe oder Kopieren einer DB-Parametergruppe.

Überlegungen zur Zeitzone

Sie können die Zeitzonenoption verwenden, um die von Ihrer Oracle-DB-Instance verwendete Systemzeitzone zu ändern. Gründe, die Zeitzone einer DB-Instance zu ändern, sind beispielsweise Kompatibilitätsanforderungen der Umgebung an einem Standort oder eine veraltete Anwendung. Mit der Zeitzonenoption wird die Zeitzone auf Host-Ebene geändert. Amazon RDS für Oracle aktualisiert die Systemzeitzone im Verlauf des Jahres automatisch. Weitere Informationen zur Systemzeitzone finden Sie unter Oracle-Zeitzone.

Wenn Sie eine Oracle DB-Instance erstellen, legt die Datenbank automatisch die Zeitzone der Datenbank fest. Die Zeitzone der Datenbank wird auch als Sommerzeit (DST, Daylight Saving Time) bezeichnet. Die Zeitzone der Datenbank unterscheidet sich von der Zeitzone des Systems.

Zwischen Oracle-Datenbankversionen können Patch-Sets oder einzelne Patches neue DST-Versionen enthalten. Diese Patches spiegeln die Änderungen der Übergangsregeln für verschiedene Zeitzonenregionen wider. Zum Beispiel kann sich eine Regierung ändern, wenn die Sommerzeit wirksam wird. Änderungen an DST-Regeln können sich auf vorhandene Daten des Datentyps TIMESTAMP WITH TIME ZONE auswirken.

Wenn Sie eine RDS für eine Oracle-Instance aktualisieren, aktualisiert Amazon RDS die Datenbankzeitzone nicht automatisch. Um die Datenbankzeitzone manuell zu aktualisieren, erstellen Sie eine neue Oracle DB-Instance mit dem gewünschten DST-Patch. Migrieren Sie dann die Daten von Ihrer aktuellen Instance in die neue Instance. Sie können Daten mit verschiedenen Techniken migrieren, einschließlich der folgenden:

  • Oracle GoldenGate

  • AWS Database Migration Service

  • Oracle Data Pump

  • Ursprünglicher Export/Import (wird ab Oracle Database 11g nicht länger für den allgemeinen Gebrauch unterstützt)

Anmerkung

Wenn Sie Daten mit Oracle Data Pump migrieren, löst das Dienstprogramm den Fehler ORA-39405 aus, wenn die Zielzeitzonenversion älter als die Quellzeitzonenversion ist.

Weitere Informationen finden Sie unter TIMESTAMP WITH TIMEZONE-Einschränkungen in der Oracle-Dokumentation.

Testen eines Upgrades

Bevor Sie ein neues Hauptversions-Upgrade für Ihre DB-Instance durchführen, stellen Sie sicher, dass Sie Ihre Datenbank und alle Anwendungen, die Zugriff auf die Datenbank haben, sorgfältig auf die Kompatibilität mit der neuen Version prüfen. Wir empfehlen Ihnen folgendes Vorgehen.

Um ein Hauptversions-Upgrade zu testen

  1. Informieren Sie sich in der Upgrade-Dokumentation von Oracle über die neue Version der Datenbank-Engine, um zu prüfen, ob es Kompatibilitätsprobleme geben könnte, die sich auf Ihre Datenbank oder Anwendungen auswirken könnten. Weitere Informationen finden Sie unter Database Upgrade Guide in der Oracle-Dokumentation.

  2. Wenn Ihre DB-Instance eine benutzerdefinierte Optionsgruppe verwendet, erstellen Sie eine neue Optionsgruppe, die kompatibel mit der neuen Version ist, auf die Sie upgraden. Weitere Informationen finden Sie unter Überlegungen zu Optionsgruppen.

  3. Wenn Ihre DB-Instance eine benutzerdefinierte Parametergruppe verwendet, erstellen Sie eine neue Parametergruppe, die kompatibel mit der neuen Version ist, auf die Sie upgraden. Weitere Informationen finden Sie unter Überlegungen zu Parametergruppen.

  4. Erstellen Sie einen DB-Snapshot der zu aktualisierenden DB-Instance. Weitere Informationen finden Sie unter Erstellen eines DB-Snapshots.

  5. Stellen Sie den DB-Snapshot wieder her, um eine neue Test-DB-Instance zu erstellen. Weitere Informationen finden Sie unter Wiederherstellen aus einem DB--Snapshot.

  6. Ändern Sie diese neue Test-DB-Instance mit den folgenden Methoden, um sie auf die neue Version upzugraden:

  7. Test durchführen:

    • Führen Sie so viele Qualitätssicherungstests mit der upgegradeten DB-Instance durch, wie nötig, um sicherzustellen, dass Ihre Datenbank und Anwendung mit der neuen Version korrekt ausgeführt werden.

    • Führen Sie alle nötigen neuen Tests aus, um die Auswirkungen von Kompatibilitätsproblemen zu bewerten, die Sie in Schritt 1 bestimmt haben.

    • Testen Sie alle gespeicherten Prozeduren, Funktionen und Auslöser.

    • Leiten Sie Testversionen Ihrer Anwendungen an die aktualisierte DB-Instance weiter. Überprüfen Sie, ob die Anwendungen mit dieser neuen Version korrekt ausgeführt werden.

    • Beurteilen Sie den Speicherplatz, den die upgegradete Instance verwendet, um zu bestimmen, ob das Upgrade zusätzlichen Speicherplatz benötigt. Es kann sein, dass Sie eine größere Instance-Klasse auswählen müssen, um die neue Version bei der Produktion zu unterstützen. Weitere Informationen finden Sie unter DB-Instance-Klassen.

  8. Wenn alle Tests erfolgreich sind, aktualisieren Sie Ihre Produktions-DB-Instance. Es wird empfohlen zu bestätigen, dass die DB-Instance ordnungsgemäß funktioniert, bevor Sie Schreibvorgänge für die DB-Instance zulassen.

Vorbereiten des automatischen Oracle 11g SE1-Upgrades

Am 01. November 2020 planen wir, mit dem automatischen Upgrade von Oracle 11g SE1 License Included (LI)-Instances auf Oracle 19c for Amazon RDS für Oracle zu beginnen. Alle 11g-Instances, einschließlich Reserved Instances, werden auf das neueste verfügbare Oracle Release Update (RU) verschoben.

Wichtig

Wenn sich Ihre DB-Instance in der Instance-Klasse db.t2.micro oder db.t3.micro befindet, wird Ihr Lease abgebrochen. Sie können neue Reserved Instances für die neue Instance-Klasse erwerben, die auf Oracle 19c SE2 ausgeführt wird. Weitere Informationen erhalten Sie vom AWS Support.

Auswählen einer Upgrade-Strategie

Wenn Ihre DB-Instance vor dem 01. November 2020 11.2.0.4 SE LI ausführt und Sie sie nicht automatisch von Amazon RDS aktualisieren lassen möchten, verwenden Sie eine der folgenden Strategien:

  • Aktualisieren Sie Ihre DB-Instance im LI-Modell auf die Oracle-Versionen 12.1, 12.2, 18c oder 19c.

  • Aktualisieren Sie Ihre 11.2-Snapshots, und stellen Sie sie dann wieder her. Weitere Informationen finden Sie unter Migration von SE2 auf EE mithilfe von Snapshots.

  • Ändern Sie Ihre Instance in das BYOL-Modell (Verwendung der eigenen Lizenz), wenn Sie über die entsprechende SE1-Lizenz verfügen. Weitere Informationen finden Sie unter Ändern des Lizenzmodells zu BYOL.

Wenn Ihre DB-Instance 11.2.0.4 SE LI ausführt und Sie ab dem 1. November 2020 automatisch von Amazon RDS aktualisieren lassen möchten, stellen Sie sicher, dass Sie die unter Funktionsweise des automatischen 11g SE1-Upgrades beschriebenen Auswirkungen verstehen.

Migration von SE2 auf EE mithilfe von Snapshots

Um das automatische Upgrade zu vermeiden, können Sie von den SE-Editionen der Oracle-Software auf Enterprise Edition migrieren. Zur Nutzung dieser Technik benötigen Sie eine nicht verwendete Oracle-Lizenz, die für die Edition und Klasse der DB-Instance geeignet ist, die Sie ausführen möchten. Eine Migration von der Enterprise Edition zu anderen Editionen ist nicht möglich.

Stellen Sie beim Aktualisieren oder Wiederherstellen von Snapshots neue mit 19c SE2 kompatible Parametergruppen bereit. Wir empfehlen, dass Sie Ihre 11g SE1- und 19c SE2-Optionsgruppen genau aneinander anpassen. Sie haben die folgenden Upgrade-Optionen:

  • Wenn Sie 11.2.0.4 SE1 LI-Snapshots haben, aktualisieren Sie diese im LI-Modell auf 12.1, 12.2, 18c oder 19c SE2.

  • Wenn Sie 11.2.0.2 oder 11.2.0.3 SE1 LI-Snapshots haben, führen Sie die folgenden Schritte aus:

    1. Aktualisieren Sie die Snapshots von 11.2.0.2 oder 11.2.0.3 auf 11.2.0.4.

    2. Aktualisieren Sie die Snapshots von 11.2.0.4 auf 12.1, 12.2, 18c oder 19c SE2 LI.

Um die Oracle Edition zu ändern und Ihre Daten zu behalten, erstellen Sie einen Snapshot Ihrer laufenden DB-Instance. Erstellen Sie dann eine neue DB-Instance der Edition, die Sie aus dem Snapshot erhalten möchten. Sofern Sie nicht Ihre alte DB-Instance behalten möchten und über die entsprechenden Oracle Database-Lizenzen verfügen, empfehlen wir Ihnen, Ihre alte DB-Instance zu löschen.

So migrieren Sie mithilfe von Snapshots von 12.2 SE2 auf 12.2 EE

  1. Stoppen Sie Ihre Anwendung.

  2. Erstellen Sie mithilfe der Anweisungen unter Erstellen eines DB-Snapshots ein Snapshot Ihrer 12.2 SE2-Instance.

  3. Stellen Sie den soeben erstellten Snapshot mit den Anweisungen unter Wiederherstellung aus einem Snapshot wieder her. Wählen Sie als Engine die Option Oracle Enterprise Edition aus.

    Um den Snapshot wiederherzustellen, erstellt Oracle eine neue DB-Instance.

  4. Geben Sie der ursprüngliche SE2-DB-Instance einen Namen entsprechend den Anweisungen unter Umbenennen einer DB-Instance. Wenn die ursprüngliche DB-Instance beispielsweise orcl1 ist, können Sie sie in orcl1-se2 umbenennen.

  5. Benennen Sie die neue EE-Instance so um, dass sie mit dem ursprünglichen Namen der SE2-Instance übereinstimmt. Wenn die ursprüngliche SE2-Instance beispielsweise den Namen orcl1 hat, benennen Sie die EE-Instance in orcl1 um. Da die neue Instance denselben Namen wie die ursprüngliche Instance hat, kann sie den Listener-Endpunkt wiederverwenden.

  6. Starten Sie Ihre Anwendung, und stellen Sie eine Verbindung mit der neuen EE-Instance her.

  7. Stellen Sie sicher, dass die Anwendung wie erwartet funktioniert, und löschen Sie dann die SE2-Instance.

Weitere Informationen zum Aktualisieren von Snapshots erhalten Sie unter Aktualisieren eines Oracle-DB-Snapshots.

Ändern des Lizenzmodells zu BYOL

Wenn Sie von LI zu BYOL wechseln, fällt Ihre DB-Instance einige Minuten lang aus. Während dieses Zeitraums verschiebt RDS for Oracle Ihre DB-Instance auf einen anderen Host. Wenn Sie Bedenken bezüglich Ausfallzeiten haben, empfehlen wir Ihnen, die Lizenzänderung auf einem wiederhergestellten Produktions-Snapshot zu testen.

Das Lizenzmodell kann mithilfe der AWS Management Console in BYOL geändert werden.

So ändern Sie das Lizenzmodell mithilfe der Konsole in BYOL

  1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Databases (Datenbanken) aus.

  3. Wählen Sie als DB identifier (DB-Bezeichner) die ID der Datenbank aus, deren Lizenzmodell Sie ändern möchten.

  4. Wählen Sie Modify aus.

  5. Wählen Sie als License model (Lizenzmodell) bring-your-own-license (Verwendung der eigenen Lizenz) aus.

  6. Klicken Sie auf Continue.

  7. Wählen Sie im Abschnitt Scheduling of modifications (Planung von Änderungen) die Option Apply immediately (Sofort anwenden) aus.

  8. Wählen Sie Modify DB Instance (DB-Instance ändern).

Um eine Optionsgruppe zu erstellen, verwenden Sie den Befehl AWS CLI modify-db-instance mit dem --license-model-Parameter.

Im folgenden Beispiel wird die Datenbank mit dem Namen orcl1 in das BYOL-Lizenzmodell geändert.

Für Linux, macOS oder Unix:

       
aws rds modify-db-instance \
    --db-instance-identifier orcl1 \
    --license_model bring-your-own-license

Für Windows:


aws rds modify-db-instance ^
    --db-instance-identifier orcl1 ^
    --license_model bring-your-own-license

Öffnen Sie zu diesem Zeitpunkt eine Stornierungsanforderung für Reserved Instances. Bitten Sie Ihren Technical Account Manager (TAM), mit dem Operationsteam für Reserved Instances zu arbeiten.

Um eine Optionsgruppe zu erstellen, rufen Sie den Amazon RDS CreateOptionGroup API-Vorgang mit dem LicenseModel-Parameter auf.

Funktionsweise des automatischen 11g SE1-Upgrades

Wir planen, nur dann mit dem automatischen Upgrade Ihrer RDS für Oracle 11.2-Instance am 01. November 2020 zu beginnen, wenn Sie keine Strategie aus dem vorherigen Abschnitt implementiert haben. Die automatische Aktualisierung erfolgt während der Wartungsfenster. Wenn jedoch keine Wartungsfenster verfügbar sind, sobald das Upgrade durchgeführt werden muss, aktualisiert Amazon RDS for Oracle die Engine sofort.

Das Upgrade erfolgt in den folgenden Phasen:

  1. Skalieren Ihrer Instance-Klasse

  2. Upgrade von 11.2.0.4 SE1 auf 19c SE2

Wichtig

Automatische Upgrades können unerwartete Folgen für AWS CloudFormation-Stacks haben. Wenn Sie sich darauf verlassen, dass Amazon RDS Ihre DB-Instances automatisch aktualisiert, können Probleme mit AWS CloudFormation auftreten.

Skalieren Ihrer Instance-Klasse

Einige DB-Instance-Typen werden für 19c nicht unterstützt. Amazon RDS skaliert die nicht unterstützte Klasse vor Beginn des automatischen Upgrades auf eine entsprechende unterstützte Klasse. In der folgenden Tabelle werden die unterstützten Klassen aufgeführt, die jeder nicht unterstützten Klasse entsprechen.

Nicht unterstützte Instance-Klasse

vCPUs in nicht unterstützter Klasse

 Speicher in nicht unterstützter Klasse

Unterstützte Instance-Klasse

vCPUs in unterstützter Klasse

 Speicher in nicht unterstützter Klasse

HugePages ist Standard?

t3.micro

2

1 GB

t3.small

2

2 GB

Nein

t2.micro

1

1 GB

t3.small

2

2 GB

Nein

t2.small

1

2 GB

t3.small

2

2 GB

Nein

t2.medium

2

4 GB

t3.medium

2

4 GB

Nein

t2.large

2

8 GB

t3.large

2

8 GB

Nein

t2.xlarge

4

16 GB

t3.xlarge

4

16 GB

Nein

t2.2xlarge

8

32 GB

t3.2xlarge

8

32 GB

Nein

m3.large

2

7,5 GB

m5.large

2

8 GB

Nein

m3.xlarge

4

15 GB

m5.xlarge

4

16 GB

Ja

m3.2xlarge

8

30 GB

m5.2xlarge

8

32 GB

Ja

r3.large

2

15,25 GB

r5.large

2

16 GB

Ja

r3.xlarge

4

30,5 GB

r5.xlarge

4

32 GB

Ja

r3.2xlarge

8

61 GB

r5.2xlarge

8

64 GB

Ja

r3.4xlarge

16

122 GB

r5.4xlarge

16

128 GB

Ja

r3.8xlarge

32

244 GB

r5.8xlarge

32

256 GB

Ja

Wenn Ihre neue Instance-Klasse standardmäßig HugePages enthält, führt das Upgrade die folgenden Schritte durch:

  1. Die Parametergruppe wird geklont. Amazon RDS legt den Initialisierungsparameter USE_LARGE_PAGES explizit auf FALSE fest.

  2. Die geklonte Parametergruppe wird auf die DB-Instance angewendet.

  3. Startet die DB-Instance neu.

  4. Die DB-Instance wird auf die neue Instance-Klasse angewendet.

Upgrade von 11.2.0.4 SE1 auf 19c SE2

Während des automatischen Upgrades führt Amazon RDS die folgenden Schritte aus:

  1. Jede benutzerdefinierte Parametergruppe wird in 19c-Parametergruppen geklont. Weitere Informationen finden Sie unter Klonen von Parametergruppen.

  2. Benutzerdefinierte Optionsgruppen werden in 19c-Optionsgruppen geklont. Weitere Informationen finden Sie unter Klonen von Optionsgruppen.

  3. Patches der DB-Instance auf 19c. Weitere Informationen finden Sie unter Anwenden der 19c-Patches.

Klonen von Parametergruppen

Während des automatischen Upgrades erstellt RDS neue 19c-Parametergruppen für 11g-Instances. Die aktualisierte Instance verwendet die neuen Parametergruppen.

RDS kopiert alle Parameter und Parameterwerte von 11g bis 19c. Ausgenommen sind die folgenden Parameter, die RDS vor dem Erstellen der Parametergruppe herausfiltert:

  • _sqlexec_progression_cost

  • exafusion_enabled

  • global_context_pool_size

  • max_connections

  • max_enabled_roles

  • o7_dictionary_access

  • optimizer_adaptive_features

  • parallel_automatic_tuning

  • parallel_degree_level

  • sec_case_sensitive_logon

  • standby_archive_dest

  • use_indirect_data_buffers

  • utl_file_dir

Klonen von Optionsgruppen

Während des automatischen Upgrades erstellt RDS neue 19c-Optionsgruppen für 11g-Instances. Die aktualisierte Instance verwendet die neuen Optionsgruppen.

In der folgenden Tabelle werden Optionen beschrieben, die eine besondere Behandlung erfordern.

Option

Besondere Hinweise zur Handhabung

OEM_AGENT

Wenn Sie eine Version des Agenten verwenden, die älter als 13.1.0.0.v1 ist, lässt Amazon RDS diese Option aus der geklonten Optionsgruppe aus. Die 19c Agent-Versionen beginnen mit einer höheren Version als die auf 11g verfügbare Version.

XMLDB

Amazon RDS lässt diese Option in geklonten Optionsgruppen aus, da diese Option für Versionen nach 11g nicht unterstützt wird.

APEX

Wenn Sie APEX- oder APEX-DEV-Version 4.1.1.v1, 4.2.6.v1, 5.0.4.v1, 5.1.2.v1, 5.1.4.v1, 18.1.v1 oder 18.2.v1 ausführen, aktualisiert Amazon RDS sie auf Version 19.2.v1. Wenn Sie APEX 19.1.v1 ausführen, kopiert Amazon RDS die Option so, wie sie ist.

SQLT

Wenn Sie SQLT 12.1.160429 oder 12.2.180331 ausführen, führt Amazon RDS eine Deinstallation und eine Aktualisierung auf 12.2.180725 aus.

Wichtig

Das automatische Upgrade löscht bereits vorhandene SQLT-Daten auf 12.1.160429 oder 12.2.180331.

Anwenden der 19c-Patches

In der letzten Phase des Upgrades wendet Amazon RDS die erforderlichen Patches an, um die DB-Engine auf 19c zu aktualisieren. Stellen Sie sicher, dass Sie die neuen 19c-Parameter und Optionsgruppen angeben, die von der DB-Instance nach Abschluss des Upgrades verwendet werden sollen.

Upgraden einer Oracle-DB-Instance

Informationen über das manuelle oder automatische Upgraden einer Oracle-DB-Instance finden Sie unter Upgrade der Engine-Version für eine DB-Instance .