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.

# Ende des Supports für RDS Custom für Oracle
<a name="RDS-Custom-for-Oracle-end-of-support"></a>

**Anmerkung**  
Hinweis zum Ende des Supports: Am 31. März 2027 AWS wird der Support für Amazon RDS Custom for Oracle eingestellt. Nach dem 31. März 2027 können Sie nicht mehr auf die Ressourcen von RDS Custom for Oracle oder RDS Custom for Oracle zugreifen. Weitere Informationen finden Sie unter [Ende des Supports für RDS Custom für Oracle](#RDS-Custom-for-Oracle-end-of-support).

## -Übersicht
<a name="RDS-Custom-for-Oracle-end-of-support-overview"></a>

 AWS Hat nach reiflicher Überlegung die Entscheidung getroffen, den Service Amazon RDS Custom for Oracle einzustellen. Der Service wird mit Wirkung zum **31. März** 2027 nicht mehr unterstützt. Dieser Leitfaden enthält detaillierte Migrationsstrategien, die Sie bei der Migration von RDS Custom for Oracle zu selbstverwalteten Oracle-Datenbanken auf Amazon Elastic Compute Cloud (Amazon EC2) unterstützen.

### Wichtige Zeitpläne
<a name="RDS-Custom-for-Oracle-end-of-support-key_timelines"></a>
+ **Vom 31. März 2026 bis 31. März 2027: Wir empfehlen Ihnen,** von RDS Custom for Oracle zur Ausführung von Oracle auf EC2 zu migrieren. Während dieses Zeitraums können Sie RDS Custom for Oracle mit den vorhandenen Funktionen und dem vorhandenen Support weiterhin verwenden.
+ **Nach dem 31. März 2027**: Sie können den Dienst RDS Custom for Oracle nicht mehr nutzen.

### Zielpublikum
<a name="RDS-Custom-for-Oracle-end-of-support-target_audience"></a>

Diese Anleitung richtet sich an:
+ Datenbankadministratoren, die für Oracle-Datenbankmigrationen verantwortlich sind
+ Cloud-Architekten planen Migrationsstrategien
+ DevOps Ingenieure, die die Datenbankinfrastruktur verwalten
+ IT-Manager, die den Migrationsprozess überwachen

### Voraussetzungen
<a name="RDS-Custom-for-Oracle-end-of-support-prerequisites"></a>

Stellen Sie vor Beginn sicher, dass Sie über Folgendes verfügen:
+ Eine aktive Amazon RDS Custom for Oracle-Instance, auf der Oracle 19c Enterprise Edition ausgeführt wird
+ Entsprechende AWS Identity and Access Management (IAM) -Berechtigungen zum Erstellen und Verwalten von EC2-Instances
+ Verständnis Ihrer Datenbankarchitektur (Nicht-CDB oder Mehrmandanten-CDB mit PDBs)
+ Planung der Netzwerkkonnektivität zwischen Quell- und Zielinstanzen
+ Backup- und Wiederherstellungsstrategie für Ihre Migration

## Optionen für die Migration
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options"></a>

Im Rahmen des Migrationsprozesses können Sie je nach Ihren Geschäftsanforderungen und Ihrem Anwendungsfall eine von zwei Migrationsoptionen wählen:

### Option 1: Aktive RMAN-Duplikation (Migration) Online/Offline
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options-RMAN"></a>

**Am besten geeignet für**
+ Workloads, die geplante Ausfallzeiten während der endgültigen Umstellung ermöglichen
+ Einfachere Migrationsanforderungen mit weniger beweglichen Teilen
+ Datenbanken, für die Sie eine einfache, einmalige Migration wünschen
+ Szenarien, in denen Sie vor der Umstellung keine kontinuierliche Synchronisation benötigen

**Schlüsselmerkmale**
+ **Ausfallzeit**: Minimale Ausfallzeit während der endgültigen Umstellung (die Datenbank bleibt während der Duplizierung online, kurze Ausfallzeit bei der endgültigen Umstellung)
+ **Komplexität**: Geringere Komplexität durch direkte Datenbankduplizierung
+ **Dauer: Die** Migrationszeit hängt von der Datenbankgröße und der Netzwerkbandbreite ab
+ **Fallback**: Erfordert die Wartung der Quelldatenbank, bis die Validierung abgeschlossen ist
+ **Online-Fähigkeit**: Die Quelldatenbank bleibt während des Duplizierungsprozesses online und zugänglich

**Migrationsansatz:** Die aktive RMAN-Duplizierung erstellt eine exakte Kopie der Quelldatenbank auf dem Ziel, indem Datenbankdateien aus der laufenden Quelldatenbank über das Netzwerk kopiert werden. Die Quelldatenbank bleibt während des Duplizierungsvorgangs online und für Anwendungen zugänglich. Bei Mehrmandantendatenbanken dupliziert RMAN automatisch die gesamte CDB einschließlich `CDB$ROOT``PDB$SEED`, und aller austauschbaren Datenbanken in einem einzigen Vorgang. Es ist nur ein kurzes Umstellungsfenster erforderlich, um Anwendungen auf die neue EC2-Instance umzuleiten.

### Option 2: Oracle Data Guard (Online-Migration)
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options-Oracle-Data-Guard"></a>

**Am besten geeignet für**
+ Produktionsworkloads, die minimale Ausfallzeiten erfordern
+ Mission-critical Datenbanken, die verfügbar bleiben müssen
+ Szenarien, in denen Sie vor der Umstellung eine kontinuierliche Synchronisation benötigen
+ Migrationen, für die eine integrierte Fallback-Funktion erforderlich ist

**Schlüsselmerkmale**
+ **Ausfallzeit**: Near-zero Ausfallzeit (Sekunden bis Minuten bei Umstellung)
+ **Komplexität**: Höhere Komplexität mit der Data Guard-Konfiguration
+ **Dauer**: Zeit für die Ersteinrichtung plus kontinuierliche Synchronisation bis zum Switchover
+ **Fallback**: Built-in Fallback-Fähigkeit, indem die Quelle im Standby-Modus belassen wird

**Migrationsansatz:** Oracle Data Guard verwaltet eine synchronisierte Standby-Datenbank, indem es kontinuierlich Redo-Logs aus der Primärdatenbank versendet und anwendet. Wenn Sie bereit sind, die Migration abzuschließen, führen Sie einen Switchover durch, der den EC2-Standby mit minimaler Ausfallzeit zum Primärserver hochstuft. Bei Datenbanken mit mehreren Mandanten schützt Data Guard automatisch die gesamte CDB, einschließlich aller PDBs.

 **Entscheidungsmatrix** 

Verwenden Sie die folgende Matrix, um die geeignete Migrationsoption auszuwählen:


|  **Aspekt**  |  **Aktive RMAN-Duplizierung**  |  **Oracle Data Guard**  | 
| --- | --- | --- | 
| **Verfügbarkeit der Quelldatenbank** | Online während der Vervielfältigung | Während des gesamten Vorgangs online | 
| **Akzeptable Ausfallzeiten** | Minuten bis Stunden (endgültige Umstellung) | Sekunden bis Minuten (Umstellung) | 
| **Komplexität der Migration** | Niedriger | Höher | 
| **Kontinuierliche Synchronisation** | Nein | Ja | 
| **Fallback-Fähigkeit** | Manuell (Quelle beibehalten) | Built-in (automatisch) | 
| **Testen vor der Umstellung** | Begrenzt | Vollständiger Test möglich | 
| **Anforderung an die Netzwerkbandbreite** | Hoch beim Duplizieren | Mäßig (kontinuierlich) | 
| **Am besten geeignet für** | Die meisten Migrationen dev/test, geplante Umstellung | Produktion, geschäftskritisch, fast keine Ausfallzeiten | 

### Überlegungen zur Architektur
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options-architecture-considerations"></a>

Beide Migrationsoptionen unterstützen zwei Oracle-Datenbankarchitekturen:

 **Non-CDB** 

Herkömmliche Oracle-Datenbanken mit einer Instanz ohne Mehrmandantenarchitektur. Diese Datenbanken:
+ Haben Sie eine einzige Datenbankinstanz
+ Verwenden Sie keine austauschbaren Datenbanken (PDBs)
+ Sind einfacher zu verwalten und zu migrieren
+ Wird in RDS Custom for Oracle in der Regel ORCL genannt

 **Mehrmandantenfähig (CDB mit PDBs)** 

Container-Datenbanken (CDB), die mehrere Pluggable Databases (PDBs) hosten, wurden in Oracle 12c eingeführt. Diese Datenbanken:
+ Haben Sie eine Container-Datenbank (CDB) mit und `CDB$ROOT` `PDB$SEED`
+ Hosten Sie eine oder mehrere austauschbare Datenbanken (PDBs)
+ Sorgen Sie für Datenbankkonsolidierung und Ressourcenisolierung
+ Wird in RDS Custom for Oracle normalerweise RDSCDB genannt
+ Verwenden Sie Oracle Managed Files (OMF) mit GUID-based Unterverzeichnissen für PDB-Datendateien

**Wichtiger Hinweis für Multitenant-Migrationen**: Die Zieldatenbank wird während des Migrationsprozesses in ORCL umbenannt (Quelle: RDSCDB → Ziel: ORCL). Dies vereinfacht die Zielkonfiguration und entspricht den Standardbenennungskonventionen.

 **Hauptunterschiede im Migrationsansatz** 


|  **Aspekt**   |  **Non-CDB**  |  **Mehrmandantenfähig (CDB mit PDBs)**  | 
| --- | --- | --- | 
| **Umfang der Migration** | Eine einzige Datenbank | Vollständige CDB mit allen PDBs | 
| **Post-migration state**  | Datenbank öffnen READ WRITE | CDB öffnet READ WRITE; PDBs im Zustand MOUNTED | 
| **PDB-Verwaltung** | N/A | PDBs müssen geöffnet und automatisches Öffnen konfiguriert werden | 
| **Bereinigen** | Einzelne Datenbank | CDB$ROOT(kaskadiert zu PDBs); behandelt allgemeine C\#\#-Benutzer | 
| **Anwendungsverbindungen** | Datenbankdienst | PDB-Dienste (nicht CDB) | 
| **Parameterdatei** | Standardparameter | Erfordert enable\_pluggable\_database=True | 
| **Komplexität** | Niedriger | Höher aufgrund mehrerer Container | 

## Allgemeine Voraussetzungen für beide Migrationsoptionen
<a name="RDS-Custom-for-Oracle-end-of-support-common-prerequisites"></a>

Bevor Sie eine der Migrationsoptionen starten, führen Sie die folgenden erforderlichen Schritte durch:

1. Starten und konfigurieren Sie die EC2-Instanz

   Starten Sie eine EC2-Instance unter Berücksichtigung der folgenden Überlegungen:
   + **Instance-Typ**: Wählen Sie einen EC2-Instance-Typ, der den Ressourcenanforderungen Ihres Workloads entspricht. Die Verwendung derselben Instance-Klasse wie Ihre benutzerdefinierte RDS-Instance ist ein guter Ausgangspunkt. Berücksichtigen Sie die Anforderungen an Arbeitsspeicher, CPU und Netzwerkbandbreite.
   + **Betriebssystem**: Oracle Linux oder Red Hat Enterprise Linux (entspricht Ihrer RDS Custom OS-Version oder ist mit dieser kompatibel)
   + **Oracle-Software**: Installieren Sie die Oracle Database-Software (dieselbe Hauptversion, Nebenversion, Release-Update und idealerweise dieselben einmaligen Patches wie RDS Custom). Stellen Sie sicher, dass die Oracle-Software in u01/app /oracle/ oder an Ihrem bevorzugten Ort installiert ist.
   + **Speicher**: Konfigurieren Sie Amazon EBS-Volumes mit geeigneter Größe und IOPS, um Ihre Workload-Anforderungen zu erfüllen. Erwägen Sie die Verwendung von gp3-Volumes für kostengünstige Leistung oder io2 Block Express für Hochleistungs-Workloads.

1. Konfigurieren Sie die Speicherarchitektur

   1. Dateisystemspeicher (für die meisten Szenarien empfohlen)
      + Verwenden Sie Standard-Dateisystemverzeichnisse für Oracle-Datendateien
      + Einfacher zu verwalten und für die meisten Workloads geeignet
      + In dieser Anleitung werden Beispiele für die Speicherung von Dateisystemen verwendet

   1. Oracle Automatic Storage Management (ASM)
      + Wenn Ihr Workload ASM erfordert, installieren und konfigurieren Sie eigenständiges ASM auf der EC2-Instance
      + Passen Sie alle Pfadparameter in der Init-Datei entsprechend an, um ASM-Festplattengruppen zu verwenden (z. B. \+DATA, \+FRA)
      + Der Migrationsprozess ist für ASM ähnlich, mit Pfadanpassungen

1. Richten Sie den Dateiübertragungsmechanismus ein

   Erstellen Sie einen Mechanismus für die Übertragung von Dateien zwischen RDS Custom- und EC2-Instances. Sie haben mehrere Möglichkeiten:

   1. Option A: Amazon S3 (für die meisten Szenarien empfohlen)
      + Erstellen Sie einen Amazon S3 S3-Bucket oder verwenden Sie einen vorhandenen
      +  AWS CLI auf beiden Instanzen installieren und konfigurieren
      + Anweisungen finden Sie unter [Erste Schritte mit dem AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html).

   1. Option B: Direkt SCP/SFTP
      + Wenn SSH-Ports zwischen den Instanzen geöffnet sind, können Sie Dateien direkt übertragen
      + Geeignet für kleine Dateien wie Parameterdateien und Passwortdateien

   1. Option C: Amazon EFS
      + Wenn Sie Amazon EFS bereits auf beiden Instances installiert haben, können Sie es als gemeinsam genutztes Dateisystem verwenden
      + Geeignet für Umgebungen mit vorhandener EFS-Infrastruktur

      In dieser Anleitung wird Amazon S3 als Beispiele verwendet, Sie können die Befehle jedoch an die von Ihnen gewählte Methode anpassen.

1. Netzwerkkonnektivität konfigurieren

   Stellen Sie die Netzwerkkonnektivität zwischen den RDS Custom- und EC2-Instances sicher:
   + **Gleiche VPC**: Sicherheitsgruppen müssen bidirektionalen Verkehr auf dem Oracle-Listener-Port zulassen (Standard 1521 oder Ihr benutzerdefinierter Port)
   + **Verschiedene VPCs (dasselbe Konto)**: VPC-Peering einrichten und Routentabellen und Sicherheitsgruppen konfigurieren
   + **Verschiedene Konten**: Richten Sie kontenübergreifendes VPC-Peering ein oder verwenden Sie Transit Gateway AWS 
   + **Konnektivität überprüfen**: Verwenden Sie Ping und Telnet, um die Konnektivität am Datenbankport zu testen

1. Erstellen Sie eine Verzeichnisstruktur auf EC2

   Die Verzeichnisstruktur hängt von Ihrer Datenbankarchitektur ab:  
**Example Für Non-CDB:**  

   ```
   # Non-CDB directories
   mkdir -p /u01/app/oracle/oradata/ORCL/controlfile/
   mkdir -p /u01/app/oracle/oradata/ORCL/datafile
   mkdir -p /u01/app/oracle/oradata/ORCL/onlinelog
   mkdir -p /u01/app/oracle/oradata/ORCL/arch
   mkdir -p /u01/app/oracle/admin/ORCL/adump
   mkdir -p /u01/app/oracle/backup
   # Set ownership
   chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL
   chown -R oracle:oinstall /u01/app/oracle/admin/ORCL
   chown -R oracle:oinstall /u01/app/oracle/backup
   ```  
**Example Für Multitenant (CDB mit PDBs)**  

   ```
   # CDB directories
   mkdir -p /u01/app/oracle/oradata/ORCL/controlfile/
   mkdir -p /u01/app/oracle/oradata/ORCL/cdb/datafile
   mkdir -p /u01/app/oracle/oradata/ORCL/pdbseed/datafile
   mkdir -p /u01/app/oracle/oradata/ORCL/onlinelog
   mkdir -p /u01/app/oracle/oradata/ORCL/arch
   mkdir -p /u01/app/oracle/admin/ORCL/adump
   mkdir -p /u01/app/oracle/backup
   # PDB directories (RDS Custom uses OMF with GUID-based paths)
   # Create a generic pdb directory - migration will create subdirectories as needed
   mkdir -p /u01/app/oracle/oradata/ORCL/pdb/datafile
   # Set ownership
   chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL
   chown -R oracle:oinstall /u01/app/oracle/admin/ORCL
   chown -R oracle:oinstall /u01/app/oracle/backup
   ```
**Anmerkung**  
RDS Custom for Oracle verwendet Oracle Managed Files (OMF) für PDB-Datendateien mit GUID-based Unterverzeichnissen (z. B.). `/rdsdbdata/db/pdb/RDSCDB_A/{{{GUID}}}/datafile/` Der Migrationsprozess erstellt automatisch die erforderliche Unterverzeichnisstruktur auf dem Ziel. Sie müssen nur die übergeordneten Verzeichnisse erstellen.

   **Speicherstrategie**: Erwägen Sie die Verwendung eines separaten EBS-Volumes für/u01/app/oracle/backup , um es nach Abschluss der Migration einfach zu trennen und zu entfernen, wodurch Speicherkosten eingespart werden.

1. Überprüfen Sie die Konfiguration der Quelldatenbank

Bevor Sie mit der Migration beginnen, überprüfen Sie Ihre Quelldatenbankkonfiguration:

1. Melden Sie sich als rdsdb-Benutzer beim RDS-Custom-Datenbankhost an und legen Sie die Umgebung fest:  
**Example**  

   ```
   # For non-CDB
   export ORACLE_HOME=/rdsdbbin/oracle.19.custom.r1.EE.1
   export ORACLE_SID=ORCL
   export PATH=$ORACLE_HOME/bin:$PATH
   
   # For multitenant CDB
   export ORACLE_HOME=/rdsdbbin/oracle.19.custom.r1.EE-CDB.1
   export ORACLE_SID=RDSCDB
   export PATH=$ORACLE_HOME/bin:$PATH
   ```

1. Connect zur Datenbank her und überprüfen Sie die Architektur:  
**Example**  

   ```
   sqlplus / as sysdba
   SQL> SELECT name, cdb, open_mode, log_mode FROM v$database;
   ```  
**Example Für Non-CDB, erwartete Ausgabe**  

   ```
   NAME CDB OPEN_MODE                 LOG_MODE
   --------- --- -------------------- ------------
   ORCL NO  READ  WRITE               ARCHIVELOG
   ```  
**Example Für Multitenant (CDB) erwartete Ausgabe:**  

   ```
   NAME    CDB  OPEN_MODE             LOG_MODE
   --------- --- -------------------- ------------
   RDSCDB    YES READ WRITE           ARCHIVELOG
   ```

1. **Wenn Sie eine CDB mit mehreren Mandanten haben**, listen Sie alle PDBs und ihren Status auf:  
**Example**  

   ```
   SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs;
   ```

   Erwartete Ausgabe (Beispiel mit einer PDB namens ORCLDB):  
**Example**  

   ```
   CON_ID     NAME                           OPEN_MODE  RES
   ---------- ------------------------------ ---------- ---
   2          PDB$SEED                       READ ONLY  NO
   3          ORCLDB                         READ WRITE NO
   ```

1. Überprüfen Sie die Gesamtgröße der Datenbank:  
**Example Für Non-CDB:**  

   ```
   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM dba_data_files;
   ```  
**Example Für Multitenant:**  

   ```
   -- Total CDB size (all containers)
   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM cdb_data_files;
   -- Size per PDB
   SQL> SELECT p.name AS pdb_name,
         ROUND(SUM(d.bytes)/1024/1024/1024, 2) AS size_gb
   FROM v$pdbs p
   JOIN cdb_data_files d ON p.con_id = d.con_id
   GROUP BY p.name, p.con_id
   ORDER BY p.con_id;
   ```

## Option 1: Physische Migration mithilfe von RMAN Active Duplication
<a name="RDS-Custom-for-Oracle-end-of-support-option-1"></a>

**Topics**
+ [Wann sollte die aktive RMAN-Duplikation verwendet werden](#RDS-Custom-for-Oracle-end-of-support-option-1-when-to-use)
+ [Überblick über die aktive RMAN-Duplizierung](#RDS-Custom-for-Oracle-end-of-support-option-1-overview)
+ [Migrationsablauf für aktive RMAN-Duplizierung](#RDS-Custom-for-Oracle-end-of-support-option-1-migration-workflow)
+ [Schritt 1: Unterbrechen Sie die benutzerdefinierte Amazon RDS-Automatisierung](#RDS-Custom-for-Oracle-end-of-support-option-1-step-1)
+ [Schritt 2: Passwort- und Parameterdateien erstellen](#RDS-Custom-for-Oracle-end-of-support-option-1-step-2)
+ [Schritt 3: Dateien auf EC2 übertragen](#RDS-Custom-for-Oracle-end-of-support-option-1-step-3)
+ [Schritt 4: Parameterdatei auf EC2 bearbeiten](#RDS-Custom-for-Oracle-end-of-support-option-1-step-4)
+ [Schritt 5: TNS und Listener konfigurieren](#RDS-Custom-for-Oracle-end-of-support-option-1-step-5)
+ [Schritt 6: Starten Sie die Datenbank in EC2 `NOMOUNT`](#RDS-Custom-for-Oracle-end-of-support-option-1-step-6)
+ [Schritt 7: Führen Sie eine aktive RMAN-Duplizierung durch](#RDS-Custom-for-Oracle-end-of-support-option-1-step-7)
+ [Schritt 8: Öffnen Sie PDBs (nur für mehrere Mandanten)](#RDS-Custom-for-Oracle-end-of-support-option-1-step-8)
+ [Schritt 9: Entfernen Sie benutzerdefinierte RDS-Objekte](#RDS-Custom-for-Oracle-end-of-support-option-1-step-9)
+ [Schritt 10: Konfigurieren Sie den automatischen Start](#RDS-Custom-for-Oracle-end-of-support-option-1-step-10)
+ [Schritt 11: Endgültige Validierung](#RDS-Custom-for-Oracle-end-of-support-option-1-step-11)

Dieser Abschnitt enthält detaillierte Schritte für die Migration Ihrer Oracle-Datenbank von RDS Custom for Oracle zu EC2 mithilfe von RMAN Active Duplication. Bei dieser Methode werden Duplikate aus einer aktiven, laufenden Datenbank erstellt, sodass die Quelle während des Migrationsprozesses online und zugänglich bleibt.

### Wann sollte die aktive RMAN-Duplikation verwendet werden
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-when-to-use"></a>

Wählen Sie aktive RMAN-Duplizierung, wenn:
+ Sie möchten, dass die Quelldatenbank während der Migration online und zugänglich bleibt
+ Sie können sich ein kurzes Umstellungsfenster für die endgültige Anwendungsumleitung leisten
+ Sie wünschen sich einen unkomplizierten Migrationsprozess mit weniger beweglichen Teilen
+ Ihre Datenbankgröße und Netzwerkbandbreite ermöglichen eine angemessene Zeit für die Duplizierung
+ Vor der Umstellung ist keine kontinuierliche Synchronisation erforderlich
+ Sie migrieren Produktions-, Entwicklungs- oder Testdatenbanken

### Überblick über die aktive RMAN-Duplizierung
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-overview"></a>

Für die aktive RMAN-Duplizierung ist weder eine Sicherung der Quelldatenbank noch ein Offlinemodus der Quelldatenbank erforderlich. Es dupliziert die aktive, laufende Quelldatenbank zum Ziel, indem Datenbankdateien über das Netzwerk kopiert werden, während die Quelle online bleibt und für Anwendungen zugänglich bleibt.

**Die wichtigsten Vorteile:**
+ **Quelle bleibt online**: Anwendungen können während der Duplizierung weiterhin auf die Quelldatenbank zugreifen
+ **Keine Sicherung erforderlich**: Eliminiert die Notwendigkeit eines Zwischenspeichers für Backups
+ **Direkte Netzwerkübertragung**: Datenbankdateien werden direkt von der Quelle zum Ziel kopiert
+ **Automatische Konsistenz**: RMAN stellt sicher, dass die doppelte Datenbank konsistent ist
+ **Einzelvorgang**: Dupliziert bei Mehrmandantenfähigkeit die gesamte CDB, einschließlich aller PDBs, in einem Vorgang

Beim Duplizieren wird eine exakte Kopie der Quelldatenbank auf dem Ziel erstellt, einschließlich aller Datendateien, Kontrolldateien und Redo-Logs. Die Quelldatenbank bedient während des gesamten Duplizierungsvorgangs weiterhin Anwendungsanfragen. Am Ende ist nur ein kurzes Umstellungsfenster erforderlich, um Anwendungen von der Quelle zum Ziel umzuleiten.

**Typischer Zeitplan**

1. **Phase der Vervielfältigung** (Quelle bleibt online): 30 Minuten bis mehrere Stunden, je nach Datenbankgröße

1. **Validierungsphase** (Quelle bleibt online): Stunden bis Tage nach Bedarf

1. **Umstellungsphase** (kurze Ausfallzeit): Minuten für die Umleitung von Anwendungen zu EC2

### Migrationsablauf für aktive RMAN-Duplizierung
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-migration-workflow"></a>

**Schritte zur benutzerdefinierten RDS-DB-Instance (Quelle):**

1. Benutzerdefinierte Amazon RDS-Automatisierung pausieren

1. Überprüfen Sie die Datenbankarchitektur (ohne CDB oder CDB mit PDBs)

1. Erstellen Sie eine Kennwortdatei und eine Parameterdatei aus der Quelldatenbank

1. Kopieren Sie die Kennwortdatei und die Parameterdatei auf die EC2-Zielinstanz

1. Stellen Sie sicher, dass die Quelldatenbank im Archiv-Log-Modus läuft

1. Konfigurieren Sie tnsnames.ora auf dem RDS Custom DB-Server

**Schritte der EC2-DB-Instance (Ziel):**

1. Bearbeiten Sie die Parameterdatei für EC2 (architekturspezifisch)

1. Konfigurieren Sie tnsnames.ora auf EC2

1. Konfigurieren Sie die Umgebung für die EC2-Instanz

1. Konfigurieren Sie Oracle Listener auf EC2

1. Starten Sie die Datenbank auf EC2 im Status NOMOUNT

**Schritte zur RMAN-Duplizierung:**

1. Führen Sie eine aktive RMAN-Duplizierung durch

1. Öffnen Sie die Datenbank (und die PDBs für Multitenant)

1. Automatisches Öffnen von PDB konfigurieren (nur für mehrere Mandanten)

1. Entfernen Sie spezifische Benutzer und Objekte für RDS Custom

1. Erstellen Sie SPFILE und konfigurieren Sie den automatischen Start

1. Setzen Sie die benutzerdefinierte Amazon RDS-Automatisierung an der Quelle fort (wenn sie aktiv bleibt)

### Schritt 1: Unterbrechen Sie die benutzerdefinierte Amazon RDS-Automatisierung
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-1"></a>

Unterbrechen Sie den Automatisierungsmodus auf Ihrer RDS-Custom-Instance, bevor Sie mit den Migrationsschritten fortfahren, um sicherzustellen, dass die Automatisierung die RMAN-Aktivität nicht beeinträchtigt. Der Parameter --resume-full-automation-mode-minute (240 Minuten = 4 Stunden in diesem Beispiel) sollte auf der Grundlage Ihrer Datenbankgröße und der erwarteten Duplizierungszeit angepasst werden.

**Wichtig**: Das Anhalten der Automatisierung hat keinen Einfluss auf die Datenbankverfügbarkeit. Die Datenbank bleibt während des Duplizierungsvorgangs online und für Anwendungen zugänglich.

**Example**  

```
aws rds modify-db-instance \
--db-instance-identifier my-custom-instance \
--automation-mode all-paused \
--resume-full-automation-mode-minute 240 \
--region us-east-1 
--query 'DBInstances[0].AutomationMode'
```

Überprüfen Sie den Automatisierungsstatus:

**Example**  

```
aws ds describe-db-instances \
--db-instance-identifier my-custom-instance \
--region us-east-1 \
--query 'DBInstances[0].AutomationMode'
```

Erwartete Ausgabe: "`all-paused`“

### Schritt 2: Passwort- und Parameterdateien erstellen
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-2"></a>

Erstellen Sie eine Passwortdatei mit`orapwd`. Rufen Sie das SYS-Passwort aus AWS Secrets Manager ab (gespeichert bei der Erstellung einer benutzerdefinierten RDS-Instanz).

**Example**  

```
# Non-CDB
$ORACLE_HOME/bin/orapwd file=/rdsdbdata/config/orapwORCL password={{<SYS_PASSWORD>}} entries=10
# Multitenant
$ORACLE_HOME/bin/orapwd file=/rdsdbdata/config/orapwRDSCDB password={{<SYS_PASSWORD>}} entries=10
```

Erstellen Sie eine Parameterdatei aus der Quelldatenbank:

**Example**  

```
sqlplus / as sysdba
SQL> CREATE PFILE='/tmp/initORCL.ora' FROM SPFILE; -- Non-CDB
SQL> CREATE PFILE='/tmp/initRDSCDB.ora' FROM SPFILE; -- Multitenant
```

Die generierte Parameterdatei wird Custom-specific RDS-Pfade und -Parameter enthalten. Zu den wichtigsten Parametern für Multitenant gehören:
+ `enable_pluggable_database`= `TRUE` (entscheidend für Mehrmandantenfähigkeit)
+ `noncdb_compatible`= `TRUE` (aus Gründen der Abwärtskompatibilität)
+ Datendateipfade für `CDB$ROOT``PDB$SEED`, und alle PDBs
+ `db_create_file_dest`und `db_create_online_log_dest_1` für OMF

### Schritt 3: Dateien auf EC2 übertragen
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-3"></a>

Wählen Sie Ihre bevorzugte Dateiübertragungsmethode. In dieser Anleitung wird Amazon S3 als Beispiele verwendet.

 **Amazon S3 verwenden:** 

#### Amazon S3 verwenden:
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-3-ec2"></a>

**Example Für Non-CDB:**  

```
# Copy files to Amazon S3 from the RDS Custom instance
aws s3 cp /tmp/initORCL.ora s3://{{<YOUR_BUCKET>}}/
aws s3 cp /rdsdbdata/config/orapwORCL s3://{{<YOUR_BUCKET>}}/
# On EC2, download files
aws s3 cp s3://{{<YOUR_BUCKET>}}/initORCL.ora $ORACLE_HOME/dbs/
aws s3 cp s3://{{<YOUR_BUCKET>}}/orapwORCL $ORACLE_HOME/dbs/
```

**Example Für Multitenant**  

```
# Copy files to Amazon S3 from the RDS Custom instance
aws s3 cp /tmp/initRDSCDB.ora s3://{{<YOUR_BUCKET>}}/
aws s3 cp /rdsdbdata/config/orapwRDSCDB s3://{{<YOUR_BUCKET>}}/
# On EC2, download and rename files to use ORCL naming
aws s3 cp s3://{{<YOUR_BUCKET>}}/initRDSCDB.ora $ORACLE_HOME/dbs/initORCL.ora
aws s3 cp s3://{{<YOUR_BUCKET>}}/orapwRDSCDB $ORACLE_HOME/dbs/orapwORCL
```

Überprüfen Sie die Dateien auf EC2:

**Example**  

```
ls -l $ORACLE_HOME/dbs/initORCL.ora
ls -l $ORACLE_HOME/dbs/orapwORCL
```

### Schritt 4: Parameterdatei auf EC2 bearbeiten
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-4"></a>

Die Parameterdatei muss sorgfältig bearbeitet werden, um eine erfolgreiche Migration sicherzustellen. Dies ist einer der wichtigsten Schritte im Migrationsprozess.

Bearbeiten Sie `$ORACLE_HOME/dbs/initORCL.ora` die EC2-Instance und nehmen Sie die folgenden wichtigen Änderungen vor:

1. **Datenbanknamen aktualisieren**: Ändern Sie für Multitenant alle Vorkommen von RDSCDB in ORCL

1. **Benutzerdefinierte RDS-Pfade in EC2-Pfade konvertieren: Ersetzen Sie /rdsdbdata/ durch//oracle/** u01/app

1. 

**Custom-specific Entfernen Sie RDS-Parameter**
   + `dg_broker_config_file1`und `dg_broker_config_file2` (falls vorhanden — zeigt an, dass ein Replikat existiert hat)
   + `standby_file_management`(falls vorhanden)
   + `spfile`(wir werden später ein neues SPFILE erstellen)
   + Alle `log_archive_dest` Parameter, die auf Standby-Ziele verweisen (nur `log_archive_dest_1` für die lokale Archivierung beibehalten)

1. **Fügen Sie Konvertierungsparameter für Dateinamen hinzu** (siehe unten)

1. **Passen Sie die Speicherparameter** an Ihre EC2-Instance-Größe an (optional, aber empfohlen)

**Grundlegendes zu Konvertierungsparametern für Dateinamen:** 

Die `LOG_FILE_NAME_CONVERT` Parameter `DB_FILE_NAME_CONVERT` und sind entscheidend für die RMAN-Duplizierung. Sie teilen RMAN mit, wie Quelldateipfade während des Duplizierungsvorgangs Zieldateipfade zugeordnet werden sollen. Ohne diese Parameter versucht RMAN, Dateien in denselben Pfaden wie die Quelle zu erstellen, was auf EC2 fehlschlägt.

**Wesentliche Überlegungen:**
+ Jeder Parameter akzeptiert Zeichenkettenpaare: Quellpfad gefolgt vom Zielpfad
+ In einem einzigen Parameter können mehrere Paare angegeben werden
+ Für Multitenant müssen Sie Pfade für `CDB$ROOT``PDB$SEED`, und alle PDBs zuordnen
+ Die Reihenfolge der Paare ist wichtig — RMAN verarbeitet sie in der angegebenen Reihenfolge
+ Pfade unterscheiden zwischen Groß- und Kleinschreibung und müssen exakt übereinstimmen

**Pfadzuordnungen:**


**Non-CDB:**  

|  **Benutzerdefinierter Pfad für RDS**  |  **EC2-Pfad**  |  **Beschreibung**  | 
| --- | --- | --- | 
| /rdsdbbin | //orakel u01/app | Oracle-Basis | 
| /rdsdbdata/db/ORCL\_A/datafile/ | /u01/app/oracle/oradata/ORCL/datafile/ | Datendateien | 
| /rdsdbdata/db/ORCL\_A/controlfile/ | /u01/app/oracle/oradata/ORCL/controlfile/ | Dateien kontrollieren | 
| /rdsdbdata/db/ORCL\_A/onlinelog/ | /u01/app/oracle/oradata/ORCL/onlinelog/ | Online-Redo-Protokolle | 
| /rdsdbdata/db/ORCL\_A/arch/ | /u01/app/oracle/oradata/ORCL/arch/ | Logs archivieren | 
| /rdsdbdata/admin/ORCL/adump | /u01/app/oracle/admin/ORCL/adump | Audit-Dump | 
| /rdsdbdata/log | //orakel u01/app | Diagnostisches Ziel | 


**Multitenant**  

|  **Benutzerdefinierter Pfad für RDS**  |  **EC2-Pfad**  |  **Beschreibung**  | 
| --- | --- | --- | 
| /rdsdbbin | /u01/app/oracle | Oracle-Basis | 
| /rdsdbdata/db/cdb/RDSCDB/datafile/ | /u01/app/oracle/oradata/ORCL/cdb/datafile/ | CDB-Root-Datendateien | 
| /rdsdbdata/db/cdb/pdbseed/ | /u01/app/oracle/oradata/ORCL/pdbseed/datafile/ | PDB$SEEDDatendateien | 
| /rdsdbdata/db/pdb/RDSCDB\_A/ | /u01/app/oracle/oradata/ORCL/pdb/datafile/ | PDB-Datendateien (OMF mit GUID) | 
| /rdsdbdata/db/cdb/RDSCDB\_A/controlfile/ | /u01/app/oracle/oradata/ORCL/controlfile/ | Steuerdateien | 
| /rdsdbdata/db/cdb/RDSCDB\_A/onlinelog/ | /u01/app/oracle/oradata/ORCL/onlinelog/ | Online-Redo-Protokolle | 
| /rdsdbdata/db/cdb/RDSCDB\_A/arch/redolog | /u01/app/oracle/oradata/ORCL/arch/ | Logs archivieren | 
| /rdsdbdata/admin/RDSCDB/adump | /u01/app/oracle/admin/ORCL/adump | Audit-Dump | 
| /rdsdbdata/log | /u01/app/oracle | Diagnostisches Ziel | 

**Konvertierungsparameter hinzufügen:**

**Example Non-CDB:**  

```
*.DB_FILE_NAME_CONVERT='/rdsdbdata/db/ORCL_A/datafile/','/u01/app/oracle/oradata/ORCL/datafile/'
*.LOG_FILE_NAME_CONVERT='/rdsdbdata/db/ORCL_A/onlinelog/','/u01/app/oracle/oradata/ORCL/onlinelog/'
```

**Example **Mehrmandantenfähig** (muss Zuordnungen für den CDB-Stamm und alle `PDB$SEED` PDB-Pfade enthalten):**  

```
*.DB_FILE_NAME_CONVERT='/rdsdbdata/db/cdb/RDSCDB/datafile/','/u01/app/oracle/oradata/ORCL/cdb/datafile/','/rdsdbdata/db/cdb/pdbseed/','/u01/app/oracle/oradata/ORCL/pdbseed/datafile/','/rdsdbdata/db/pdb/RDSCDB_A/','/u01/app/oracle/oradata/ORCL/pdb/datafile/'
 *.LOG_FILE_NAME_CONVERT='/rdsdbdata/db/cdb/RDSCDB_A/onlinelog/','/u01/app/oracle/oradata/ORCL/onlinelog/'
```

**Wichtig**: Stellen Sie bei Multitenant sicher, dass `enable_pluggable_database` = in der Parameterdatei vorhanden `TRUE` ist. RDS Custom verwendet OMF für PDB-Datendateien mit GUID-based Unterverzeichnissen — die Pfadzuweisung erledigt dies automatisch.

 **Vollständige Beispiel-Parameterdateien:** 

**Example Beispiel für eine Non-CDB Parameterdatei (`initORCL.ora`):**  

```
ORCL.__data_transfer_cache_size=0
ORCL.__db_cache_size=6039797760
ORCL.__inmemory_ext_roarea=0
ORCL.__inmemory_ext_rwarea=0
ORCL.__java_pool_size=0
ORCL.__large_pool_size=33554432
ORCL.__oracle_base='/u01/app/oracle'
ORCL.__pga_aggregate_target=4966055936
ORCL.__sga_target=7449083904
ORCL.__shared_io_pool_size=134217728
ORCL.__shared_pool_size=1207959552
ORCL.__streams_pool_size=0
ORCL.__unified_pga_pool_size=0
*.archive_lag_target=300
*.audit_file_dest='/u01/app/oracle/admin/ORCL/adump'
*.compatible='19.0.0'
*.control_files='/u01/app/oracle/oradata/ORCL/controlfile/control-01.ctl'
*.db_block_checking='MEDIUM'
*.db_create_file_dest='/u01/app/oracle/oradata/ORCL'
*.db_name='ORCL'
*.db_recovery_file_dest_size=1073741824
*.db_unique_name='ORCL'
*.dbfips_140=FALSE
*.diagnostic_dest='/u01/app/oracle'
*.filesystemio_options='setall'
*.heat_map='OFF'
*.job_queue_processes=50
*.local_listener='(address=(protocol=tcp)(host=)(port=1521))'
*.log_archive_dest_1='location="/u01/app/oracle/oradata/ORCL/arch", valid_for=(ALL_LOGFILES,ALL_ROLES)'
*.log_archive_format='-%s-%t-%r.arc'
*.max_string_size='STANDARD'
*.memory_max_target=12385852416
*.memory_target=12385852416
*.open_cursors=300
*.pga_aggregate_target=0
*.processes=1673
*.recyclebin='OFF'
*.sga_target=0
*.undo_tablespace='UNDO_T1'
*.use_large_pages='FALSE'
*.DB_FILE_NAME_CONVERT='/rdsdbdata/db/ORCL_A/datafile/','/u01/app/oracle/oradata/ORCL/datafile/'
*.LOG_FILE_NAME_CONVERT='/rdsdbdata/db/ORCL_A/onlinelog/','/u01/app/oracle/oradata/ORCL/onlinelog/'
```

**Example Beispiel für eine Multitenant-Parameterdatei (`initORCL.ora`):**  

```
ORCL.__data_transfer_cache_size=0
ORCL.__db_cache_size=6006243328
ORCL.__inmemory_ext_roarea=0
ORCL.__inmemory_ext_rwarea=0
ORCL.__java_pool_size=0
ORCL.__large_pool_size=33554432
ORCL.__oracle_base='/u01/app/oracle'
ORCL.__pga_aggregate_target=4966055936
ORCL.__sga_target=7415529472
ORCL.__shared_io_pool_size=134217728
ORCL.__shared_pool_size=1207959552
ORCL.__streams_pool_size=0
ORCL.__unified_pga_pool_size=0
*.archive_lag_target=300
*.audit_file_dest='/u01/app/oracle/admin/ORCL/adump'
*.compatible='19.0.0'
*.control_files='/u01/app/oracle/oradata/ORCL/controlfile/control-01.ctl'
*.db_block_checking='MEDIUM'
*.db_create_file_dest='/u01/app/oracle/oradata/ORCL/pdb/datafile'
*.db_create_online_log_dest_1='/u01/app/oracle/oradata/ORCL'
*.db_name='ORCL'
*.db_recovery_file_dest_size=1073741824
*.db_unique_name='ORCL'
*.dbfips_140=FALSE
*.diagnostic_dest='/u01/app/oracle'
*.enable_pluggable_database=TRUE
*.filesystemio_options='setall'
*.heat_map='OFF'
*.job_queue_processes=50
*.local_listener='(address=(protocol=tcp)(host=)(port=1521))'
*.log_archive_dest_1='location="/u01/app/oracle/oradata/ORCL/arch", valid_for=(ALL_LOGFILES,ALL_ROLES)'
*.log_archive_format='-%s-%t-%r.arc'
*.max_string_size='STANDARD'
*.memory_max_target=12361688064
*.memory_target=12361688064
*.noncdb_compatible=TRUE
*.open_cursors=300
*.pga_aggregate_target=0
*.processes=1670
*.recyclebin='OFF'
*.sga_target=0
*.undo_tablespace='UNDO_T1'
*.use_large_pages='FALSE'
*.DB_FILE_NAME_CONVERT='/rdsdbdata/db/cdb/RDSCDB/datafile/','/u01/app/oracle/oradata/ORCL/cdb/datafile/','/rdsdbdata/db/cdb/pdbseed/','/u01/app/oracle/oradata/ORCL/pdbseed/datafile/','/rdsdbdata/db/pdb/RDSCDB_A/','/u01/app/oracle/oradata/ORCL/pdb/datafile/'
*.LOG_FILE_NAME_CONVERT='/rdsdbdata/db/cdb/RDSCDB_A/onlinelog/','/u01/app/oracle/oradata/ORCL/onlinelog/'
```

**Erläuterungen zu den wichtigsten Parametern:**
+ `enable_pluggable_database=TRUE`: Erforderlich für Multitenant-CDB. Dieser Parameter aktiviert die Funktion für austauschbare Datenbanken.
+ `noncdb_compatible=TRUE`: Wird von RDS Custom aus Gründen der Abwärtskompatibilität festgelegt. Kann je nach Ihren Anforderungen beibehalten oder entfernt werden.
+ `db_create_file_dest`: Gibt den Standardspeicherort für Oracle Managed Files (OMF) an. Bei Multitenant verweist dies auf das PDB-Datendateiverzeichnis.
+ `db_create_online_log_dest_1`: Gibt den Speicherort für Online-Redo-Logs an, wenn OMF verwendet wird.
+ `DB_FILE_NAME_CONVERT`: Kritisch für die RMAN-Duplizierung. Ordnet Quelldatendateipfade Zielpfaden zu.
+ `LOG_FILE_NAME_CONVERT`: Ordnet Quell-Redo-Log-Pfade Zielpfaden zu.
+ `memory_target`und`memory_max_target`: Passen Sie diese basierend auf Ihrem EC2-Instance-Speicher an. Die angegebenen Werte sind Beispiele.
+ `processes`: Maximale Anzahl von Betriebssystemprozessen, die eine Verbindung zu Oracle herstellen können. Passen Sie es an Ihre Arbeitslast an.

**Richtlinien zur Speichergröße:**

Bei der Anpassung der Speicherparameter für Ihre EC2-Instance:


|  **EC2-Instance-Speicher**  |  **Empfohlenes memory\_target**  |  **Empfohlenes memory\_max\_target**  | 
| --- | --- | --- | 
| 16 GB | 12 GB (12884901888 Byte) | 14 GB (15032385536 Byte) | 
| 32 GB | 24 GB (25769803776 Byte) | 28 GB (30064771072 Byte) | 
| 64 GB | 48 GB (51539607552 Byte) | 56 GB (60129542144 Byte) | 
| 128 GB | 96 GB (103079215104 Byte) | 112 GB (120259084288 Byte) | 

Lassen Sie etwa 20-25% des Systemspeichers für das Betriebssystem und andere Prozesse übrig.

### Schritt 5: TNS und Listener konfigurieren
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-5"></a>

Fügen Sie auf beiden Instanzen TNS-Einträge hinzu zu: `tnsnames.ora`

**Example Non-CDB:**  

```
DB_SOURCE = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<RDS_CUSTOM_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL)))
DB_TARGET = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<EC2_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL)))
```

**Example Mehrmandantenfähig:**  

```
DB_SOURCE = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<RDS_CUSTOM_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = RDSCDB)))
DB_TARGET = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<EC2_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL)))
```

**Example Listener auf EC2 konfigurieren (): `$ORACLE_HOME/network/admin/listener.ora`**  

```
LISTENER = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<EC2_IP>}})(PORT = 1521)))
SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = ORCL) (ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1) (SID_NAME = ORCL)))
```

**Example Listener starten:**  

```
lsnrctl start
```

**Anmerkung**  
Bei der aktiven RMAN-Duplizierung stellen die TNS-Einträge über SID (nicht SERVICE\_NAME) eine Verbindung zur Datenbankinstanz her. Bei Mehrmandantenfähigkeit wird eine Verbindung zur CDB hergestellt, und RMAN dupliziert automatisch alle PDBs.

### Schritt 6: Starten Sie die Datenbank in EC2 `NOMOUNT`
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-6"></a>

**Example**  

```
export ORACLE_SID=ORCL
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH

sqlplus / as sysdba

SQL> STARTUP NOMOUNT PFILE='$ORACLE_HOME/dbs/initORCL.ora';
```

**Example Überprüfen Sie die Parameter:**  

```
SQL> SHOW PARAMETER db_name
SQL> SHOW PARAMETER control_files
SQL> SHOW PARAMETER enable_pluggable_database -- For multitenant
```

### Schritt 7: Führen Sie eine aktive RMAN-Duplizierung durch
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-7"></a>

Die aktive RMAN-Duplizierung kopiert die Datenbank von der aktiven, laufenden Quelle auf das Ziel. Die Quelldatenbank bleibt während des gesamten Vorgangs online und für Anwendungen zugänglich.

Connect RMAN sowohl mit der Quell- als auch mit der Zielinstanz:

**Example**  

```
rman target sys/{{<password>}}@DB_SOURCE auxiliary sys/{{<password>}}@DB_TARGET
```

**Example Erwartete Ausgabe für Nicht-CDB:**  

```
Recovery Manager: Release 19.0.0.0.0 - Production
connected to target database: ORCL (DBID=4089929259)
connected to auxiliary database: ORCL (not mounted)
```

**Example Erwartete Ausgabe für Multitenant:**  

```
Recovery Manager: Release 19.0.0.0.0 - Production
connected to target database: RDSCDB (DBID=4089929259)
connected to auxiliary database: ORCL (not mounted)
```

**Example Führen Sie den aktiven Duplikationsbefehl aus:**  

```
RMAN> DUPLICATE DATABASE TO 'ORCL' FROM ACTIVE DATABASE NOFILENAMECHECK;
```

**Anmerkung**  
Die **Quelle bleibt online**: Die Quelldatenbank bedient während der Duplizierung weiterhin Anwendungsanfragen
**Für Nicht-CDB**: Dadurch wird die gesamte Datenbank dupliziert, während sie online bleibt
**Für mehrere Mandanten**: Dadurch wird die gesamte CDB einschließlich`CDB$ROOT`, und aller PDBs in einem einzigen Vorgang dupliziert`PDB$SEED`, während die Quelle online bleibt
**NOFILENAMECHECK**: Ermöglicht es RMAN, fortzufahren, auch wenn sich die Dateinamen zwischen Quelle und Ziel unterscheiden
**Dauer**: Hängt von der Datenbankgröße und der Netzwerkbandbreite ab. Bei einer 100-GB-Datenbank sollten Sie mit 30-60 Minuten rechnen
**Auswirkungen auf das Netzwerk:** Hohe Auslastung der Netzwerkbandbreite während der Duplizierung, aber der Zugriff auf die Quelldatenbank bleibt bestehen

**Der aktive RMAN-Duplizierungsprozess umfasst mehrere Phasen:**

1. Verbindung zu Quell- und Zieldatenbanken herstellen

1. Eine `SPFILE` aus dem Speicher auf dem Ziel erstellen

1. Die Steuerdatei auf dem Ziel wiederherstellen

1. Mounten der Zieldatenbank

1. Kopieren aller Datendateien von der Quelle zum Ziel über das Netzwerk (Quelle bleibt online)

1. Die Zieldatenbank wird wiederhergestellt

1. Öffnen der Zieldatenbank mit `RESETLOGS`

**Während der Duplizierung gilt für die Quelldatenbank:**
+ Bleibt im Modus `READ WRITE`
+ Nimmt weiterhin Verbindungen an
+ Verarbeitet Transaktionen normal
+ Generiert Redo-Logs normal
+ Ist für Anwendungen uneingeschränkt zugänglich

**Example Überwachen Sie den Fortschritt in einer anderen Sitzung:**  

```
SQL> SELECT sid, serial#, sofar, totalwork, ROUND(sofar/totalwork*100,2) pct_complete
FROM v$session_longops WHERE totalwork > 0 AND sofar <> totalwork;
```

 **Detaillierte Überwachung und Fehlerbehebung bei der RMAN-Duplizierung:** 

Während der RMAN-Duplizierung können Sie ihren Fortschritt mit verschiedenen Methoden überwachen:

1. **Überwachen Sie die RMAN-Ausgabe:**

   In der RMAN-Sitzung werden detaillierte Fortschrittsinformationen angezeigt, darunter:
   + Kanalzuweisung
   + Fortschritt beim Kopieren der Datendatei
   + Voraussichtlicher Fertigstellungszeitraum
   + Verarbeitete Bytes

   ```
   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00001 name=/rdsdbdata/db/ORCL_A/datafile/system01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/system01.dbf tag=TAG20260303T120000
   channel ORA_AUX_DISK_1: datafile copy complete, elapsed time: 00:05:23
   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00003 name=/rdsdbdata/db/ORCL_A/datafile/sysaux01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/sysaux01.dbf tag=TAG20260303T120000
   ```  
**Example Beispielausgabe:**  

   ```
   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00001 name=/rdsdbdata/db/ORCL_A/datafile/system01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/system01.dbf tag=TAG20260303T120000
   channel ORA_AUX_DISK_1: datafile copy complete, elapsed time: 00:05:23
   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00003 name=/rdsdbdata/db/ORCL_A/datafile/sysaux01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/sysaux01.dbf tag=TAG20260303T120000
   ```

1.  **Überwachen Sie lang andauernde Operationen:**   
**Example In einer separaten SQL\*Plus-Sitzung auf der EC2-Zielinstanz:**  

   ```
   SQL> SELECT sid, serial#, opname, sofar, totalwork,
          ROUND(sofar/totalwork*100,2) pct_complete,
          time_remaining, elapsed_seconds
   FROM v$session_longops
   WHERE totalwork > 0 AND sofar <> totalwork
   ORDER BY start_time;
   ```

**Diese Abfrage zeigt:**
   + `opname`: Name der Operation (z. B. „RMAN: vollständige Datendateiwiederherstellung“)
   + `sofar`: Bisher verarbeitete Blöcke
   + `totalwork`: Gesamtzahl der zu verarbeitenden Blöcke
   + `pct_complete`: Prozentsatz abgeschlossen
   + `time_remaining`: Geschätzte verbleibende Sekunden
   + `elapsed_seconds`: Bisher verstrichene Zeit

1. **RMAN-Kanäle überwachen:**  
**Example**  

   ```
   SQL> SELECT sid, serial#, context, sofar, totalwork,
          ROUND(sofar/totalwork*100,2) pct_complete
          FROM v$session_longops
   WHERE opname LIKE 'RMAN%'
          AND totalwork > 0
          AND sofar <> totalwork;
   ```

1. **Überprüfen Sie das Warnungsprotokoll:**  
**Example Überwachen Sie das Alert-Log auf der EC2-Zielinstanz auf Fehler oder Warnungen:**  

   ```
   tail -f $ORACLE_BASE/diag/rdbms/orcl/ORCL/trace/alert_ORCL.log
   ```

**Häufige Probleme bei der RMAN-Duplizierung:**
   + **Netzwerk-Timeout**

     ```
     RMAN-03009: failure of duplicate command on ORA_AUX_DISK_1 channel
     ORA-03135: connection lost contact
     ```

     **Lösung**: Erhöhen Sie die Netzwerk-Timeout-Werte in beiden `sqlnet.ora` Fällen:

     ```
     SQLNET.RECV_TIMEOUT=600
     SQLNET.SEND_TIMEOUT=600
     ```
   + **Nicht genügend Speicherplatz auf dem Ziel**

     ```
     RMAN-03009: failure of duplicate command
     ORA-19504: failed to create file "/u01/app/oracle/oradata/ORCL/datafile/users01.dbf"
     ORA-27040: file create error, unable to create file
     Linux-x86_64 Error: 28: No space left on device
     ```

     **Lösung**: Überprüfen Sie den verfügbaren Speicherplatz und fügen Sie mehr EBS-Volume-Kapazität hinzu:

     ```
     df -h /u01/app/oracle/oradata
     ```
   + **Fehler in der Parameterdatei**

     ```
     RMAN-05021: this configuration cannot be used
     RMAN-06004: ORACLE error from auxiliary database: ORA-01261: Parameter db_create_file_dest destination string cannot be translated
     ```

     **Lösung**: Stellen Sie sicher, dass alle Verzeichnisse in der Parameterdatei existieren und über die entsprechenden Berechtigungen verfügen.
   + **Die Passwortdatei stimmt nicht überein**

     ```
     RMAN-00571: ===========================================================
     RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
     RMAN-00571: ===========================================================
     RMAN-03002: failure of duplicate command at 03/03/2026 12:00:00
     RMAN-06136: ORACLE error from auxiliary database: ORA-01017: invalid username/password; logon denied
     ```

     **Lösung**: Stellen Sie sicher, dass die Passwortdatei auf dem Ziel mit der Quelle übereinstimmt und den richtigen Namen hat (`orapwORCL`).

### Schritt 8: Öffnen Sie PDBs (nur für mehrere Mandanten)
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-8"></a>

Nach Abschluss der RMAN-Duplizierung ist die CDB auf EC2 im `READ WRITE` Modus geöffnet, aber alle PDBs befinden sich im Status. `MOUNTED` Dieses Verhalten ist zu erwarten — Sie müssen sie manuell öffnen.

Überprüfen Sie den aktuellen PDB-Status:

```
SQL> SELECT con_id, name, open_mode FROM v$pdbs;
```

Erwartete Ausgabe (Beispiel mit einer benannten `ORCLDB` PDB):

```
CON_ID     NAME                           OPEN_MODE
---------- ------------------------------ ----------
2          PDB$SEED                       READ ONLY
3          ORCLDB                         MOUNTED
```

Alle PDBs öffnen:

```
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;
Pluggable database altered.
```

Stellen Sie sicher, dass alle PDBs jetzt im `READ WRITE` folgenden Modus geöffnet sind:

```
SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs;
```

Erwartete Ausgabe:

```
CON_ID     NAME                           OPEN_MODE  RES
---------- ------------------------------ ---------- ---
2          PDB$SEED                       READ ONLY  NO
3          ORCLDB                         READ WRITE NO
```

Konfigurieren Sie das automatische Öffnen beim Start mit der Save-State-Methode (empfohlen für Oracle 19c):

```
SQL> ALTER PLUGGABLE DATABASE ALL SAVE STATE;
Pluggable database altered.
```

Dadurch wird Oracle angewiesen, sich den aktuellen Öffnungsstatus von PDBs zu merken und ihn beim Start der CDB wiederherzustellen.

Überprüfen Sie den gespeicherten Status:

```
SQL> SELECT con_name, instance_name, state FROM dba_pdb_saved_states;
```

Stellen Sie sicher, dass die PDB-Dienste beim Listener registriert sind:

```
lsnrctl services
```

Die erwartete Ausgabe sollte Dienste für die CDB und jede PDB enthalten. Wenn Dienste nicht angezeigt werden:

```
SQL> ALTER SYSTEM REGISTER;
```

Dann überprüfen Sie erneut mit`lsnrctl services`.

### Schritt 9: Entfernen Sie benutzerdefinierte RDS-Objekte
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-9"></a>

Da es sich jetzt um eine selbstverwaltete Datenbank auf EC2 handelt, sollten Sie Custom-specific RDS-Benutzer und -Objekte entfernen. Der Bereinigungsprozess unterscheidet sich zwischen Architekturen, die keine CDB sind, und Architekturen mit mehreren Mandanten.

**Wichtig**  
Bevor Sie RDS-specific Benutzer und Tablespaces löschen, stellen Sie sicher, dass keine Anwendungsobjekte unter diesen Schemas existieren:

```
SQL> SELECT owner, object_type, COUNT(*)
FROM dba_objects
WHERE owner IN ('RDSADMIN', 'RDS_DATAGUARD')
  AND object_name NOT LIKE 'RDS%'
  AND object_name NOT LIKE 'SYS_%'
GROUP BY owner, object_type;
```

Wenn Anwendungsobjekte gefunden werden, migrieren Sie sie in die entsprechenden Anwendungsschemas, bevor Sie fortfahren.

**Example Non-CDB:**  

```
SQL> DROP USER RDSADMIN CASCADE;
SQL> DROP USER RDS_DATAGUARD CASCADE;
SQL> DROP DIRECTORY OPATCH_INST_DIR;
SQL> DROP DIRECTORY OPATCH_LOG_DIR;
SQL> DROP DIRECTORY OPATCH_SCRIPT_DIR;
SQL> DROP TABLESPACE RDSADMIN INCLUDING CONTENTS AND DATAFILES;

-- Verify removal
SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%';
```

Erwartete Ausgabe: `no rows selected`

**Mehrmandantenfähig:**

In einer Umgebung mit mehreren Mandanten erstellt RDS Custom gemeinsame Benutzer, `CDB$ROOT` die in allen PDBs sichtbar sind. Sie müssen aufräumen von. `CDB$ROOT`

```
-- Connect to CDB$ROOT
SQL> SHOW CON_NAME;
-- Check for RDS-specific common users (including C## prefixed users)
SQL> SELECT username, common, con_id FROM cdb_users
WHERE username LIKE '%RDS%' OR username LIKE 'C##RDS%'
ORDER BY username;

-- Drop non-common users
SQL> DROP USER RDSADMIN CASCADE;
SQL> DROP USER RDS_DATAGUARD CASCADE;

-- If any C## common users exist
-- SQL> DROP USER C##RDSADMIN CASCADE
;
-- Drop directories and tablespace
SQL> DROP DIRECTORY OPATCH_INST_DIR;
SQL> DROP DIRECTORY OPATCH_LOG_DIR;
SQL> DROP DIRECTORY OPATCH_SCRIPT_DIR;
SQL> DROP TABLESPACE RDSADMIN INCLUDING CONTENTS AND DATAFILES;

-- Verify removal from CDB$ROOT
SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%';

-- Verify removal from each PDB
SQL> ALTER SESSION SET CONTAINER = {{<PDB_NAME>}};
SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%';
```

Erwartete Ausgabe für alle Abfragen: `no rows selected`

### Schritt 10: Konfigurieren Sie den automatischen Start
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-10"></a>

Erstellen`SPFILE`:

```
SQL> CREATE SPFILE FROM PFILE='$ORACLE_HOME/dbs/initORCL.ora';
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;
```

Stellen Sie bei Multitenant sicher, dass die PDBs geöffnet sind:

```
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;
```

Bearbeiten: `/etc/oratab`

```
ORCL:/u01/app/oracle/product/19.0.0/dbhome_1:Y
```

### Schritt 11: Endgültige Validierung
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-11"></a>

**Example Non-CDB:**  

```
SQL> SELECT name, open_mode, log_mode FROM v$database;
SQL> SELECT SUM(bytes)/1024/1024/1024 AS size_gb FROM dba_data_files;
SQL> SELECT COUNT(*) FROM dba_objects WHERE status = 'INVALID';
```

**Example Mehrmandantenfähig:**  

```
SQL> SELECT name, open_mode, log_mode, cdb FROM v$database;
SQL> SELECT con_id, name, open_mode FROM v$pdbs;
SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM cdb_data_files;
SQL> SELECT con_id, COUNT(*) FROM cdb_objects WHERE status = 'INVALID' GROUP BY con_id;
```

```
Test application connectivity:
# Non-CDB
sqlplus {{<app_user>}}/{{<password>}}@{{<EC2_IP>}}:1521/ORCL

# Multitenant (connect to PDB)
sqlplus {{<app_user>}}/{{<password>}}@{{<EC2_IP>}}:1521/{{<PDB_NAME>}}
```

 **Schritt 12: Setzen Sie die benutzerdefinierte RDS-Automatisierung fort** 

```
aws rds modify-db-instance \
--db-instance-identifier my-custom-instance \
--automation-mode full \
--region us-east-1
```

 

## Option 2: Physische Migration mit Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2"></a>



Dieser Abschnitt enthält detaillierte Schritte für die Migration Ihrer Oracle-Datenbank von RDS Custom for Oracle zu EC2 mithilfe von Oracle Data Guard. Diese Methode eignet sich für Migrationen, die nur minimale Ausfallzeiten erfordern.

### Wann sollte Oracle Data Guard verwendet werden
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-when-use-odg"></a>

**Wählen Sie Oracle Data Guard, wenn:**
+ Sie benötigen minimale Ausfallzeiten (Sekunden bis Minuten für den Switchover)
+ Sie migrieren produktive oder unternehmenskritische Datenbanken
+ Vor der Umstellung benötigen Sie eine kontinuierliche Synchronisation
+ Sie benötigen eine integrierte Fallback-Funktion
+ Sie müssen die Zieldatenbank testen, bevor Sie mit der Migration beginnen

### Überblick über Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-odg-overview"></a>

Oracle Data Guard verwaltet eine synchronisierte Standby-Datenbank, indem es kontinuierlich Redo-Logs aus der Primärdatenbank versendet und anwendet. Wenn Sie bereit sind, die Migration abzuschließen, führen Sie einen Switchover durch, der den EC2-Standby mit minimaler Ausfallzeit (Sekunden bis Minuten) zum Primärserver hochstuft. Bei Datenbanken mit mehreren Mandanten schützt Data Guard automatisch die gesamte CDB, einschließlich aller PDBs. Von einem beliebigen PDB generiertes Redo wird in den Standby-Modus übertragen und auf den entsprechenden PDB im Standby-Modus angewendet.

### Migrations-Workflow für Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-odg-workflow"></a>

**Schritte der benutzerdefinierten RDS-DB-Instance (primär):**

1. Benutzerdefinierte Amazon RDS-Automatisierung pausieren

1. Überprüfen Sie die Datenbankarchitektur (ohne CDB oder CDB mit PDBs)

1. Vergewissern Sie sich, dass die Primärdatenbank im Archivprotokollmodus läuft und aktiviert ist `FORCE_LOGGING`

1. Erstellen Sie eine Passwortdatei

1. Führen Sie eine RMAN-Online-Sicherung der Primärdatenbank durch (oder verwenden Sie aktive Duplizierung)

1. Erstellen Sie eine Parameterdatei aus der Quelldatenbank

1. Kopieren Sie die Backup-Sätze, die Parameterdatei und die Kennwortdatei auf die EC2-Zielinstanz

**Schritte der EC2-DB-Instance (Standby):**

1. Kopieren Sie alle Dateien von der Quelle zur EC2-Instance

1. Kopieren Sie die Passwortdatei auf die EC2-Instance

1. Bearbeiten Sie die Parameterdatei für EC2 (architekturspezifisch)

1. Erstellen Sie die Serverparameterdatei aus der Parameterdatei

1. Stellen Sie die Standby-Kontrolldatei und die Datenbank wieder her

**Schritte zur Konfiguration von Data Guard:**

1. Konfigurieren Sie Oracle-Listener auf beiden Instanzen

1. Konfigurieren Sie tnsnames.ora auf beiden Instanzen

1. Starten Sie den Oracle Data Guard Broker auf beiden Instanzen (optional, aber empfohlen)

1. Aktivieren Sie die Oracle Data Guard-Konfiguration

1. Konfigurieren Sie fal\_server und fal\_client auf der EC2-Standby-Instanz

1. Konfigurieren Sie die Standby-Redo-Log-Dateien auf beiden Instanzen

1. Stellen Sie die Standby-Instanz wieder her

1. Führen Sie den manuellen Switchover durch

1. Öffnen Sie die Datenbank (und die PDBs für Multitenant)

1. Automatisches Öffnen von PDB konfigurieren (nur für mehrere Mandanten)

1. Entfernen Sie spezifische Benutzer und Objekte für RDS Custom

1. Erstellen Sie SPFILE und konfigurieren Sie den automatischen Start

### Schritt 1: Unterbrechen Sie die benutzerdefinierte Amazon RDS-Automatisierung
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-1"></a>

Unterbrechen Sie den Automatisierungsmodus auf Ihrer RDS Custom-Instance. Der `--resume-full-automation-mode-minute` Parameter sollte auf der Grundlage Ihrer Datenbankgröße und der erwarteten Data Guard-Setup-Zeit angepasst werden.

```
aws rds modify-db-instance \
  --db-instance-identifier my-custom-instance \
  --automation-mode all-paused \
  --resume-full-automation-mode-minute 480 \
  --region us-east-1
```

Überprüfen Sie den Automatisierungsstatus:

```
aws rds describe-db-instances \
  --db-instance-identifier my-custom-instance \
  --region us-east-1 \
  --query 'DBInstances[0].AutomationMode'
```

Erwartete Ausgabe: "`all-paused`“

### Schritt 2: Bestätigen Sie den Archivprotokollmodus und `FORCE_LOGGING`
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-2"></a>

Oracle Data Guard erfordert, dass sich die Primärdatenbank im Archiv-Log-Modus befindet und die erzwungene Protokollierung aktiviert ist:

```
sqlplus / as sysdba
SQL> SELECT log_mode, force_logging FROM v$database;
```

Erwartete Ausgabe:

```
LOG_MODE     FORCE_LOGGING
------------ -------------
ARCHIVELOG   YES
```

Wenn die erzwungene Protokollierung nicht aktiviert ist, führen Sie Folgendes aus:

```
SQL> ALTER DATABASE FORCE LOGGING;
```

### Schritt 3: Passwort- und Parameterdateien erstellen
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-3"></a>

Erstellen Sie eine Passwortdatei mit`orapwd`. Rufen Sie das SYS-Passwort von AWS Secrets Manager ab.

```
# Non-CDB
$ORACLE_HOME/bin/orapwd file=/rdsdbdata/config/orapwORCL password={{<SYS_PASSWORD>}} entries=10

# Multitenant
$ORACLE_HOME/bin/orapwd file=/rdsdbdata/config/orapwRDSCDB password={{<SYS_PASSWORD>}} entries=10
```

Erstellen Sie eine Parameterdatei aus der Quelldatenbank:

```
sqlplus / as sysdba
SQL> CREATE PFILE='/tmp/initORCL.ora' FROM SPFILE; -- Non-CDB
SQL> CREATE PFILE='/tmp/initRDSCDB.ora' FROM SPFILE; -- Multitenant
```

### Schritt 4: Führen Sie ein RMAN-Backup durch oder verwenden Sie aktive Duplizierung
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4"></a>

Sie haben zwei Möglichkeiten, die Standby-Datenbank zu erstellen:

#### Option A: RMAN-Online-Backup (für die meisten Szenarien empfohlen)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4-a"></a>

Erstellen Sie ein Backup-Verzeichnis und sichern Sie die Datenbank:

```
mkdir -p /rdsdbdata/backup
rman target /
RMAN> run {
  backup as compressed backupset
  filesperset 2
  format '/rdsdbdata/backup/db_%U'
  database;
  sql 'alter system archive log current';
  backup as compressed backupset
  filesperset 50
  format '/rdsdbdata/backup/arch_%U'
  archivelog all;
}

RMAN> backup current controlfile for standby format '/rdsdbdata/backup/standby.ctl';
```

**Anmerkung**  
Bei Multitenant sichert das Datenbankschlüsselwort automatisch die gesamte CDB einschließlich aller PDBs.

#### Option B: Aktive Duplizierung (alternative Methode)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4-b"></a>

Überspringen Sie den Backup-Schritt und verwenden Sie die aktive RMAN-Duplizierung, um den Standby-Modus direkt über das Netzwerk aufzubauen. Dadurch werden Backup-Speicher und Dateiübertragungen überflüssig. Führen Sie nach der Konfiguration von TNS und Listenern (siehe unten) Folgendes aus:

```
RMAN> DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE DORECOVER;
```

Diese Anleitung konzentriert sich auf Option A (Backup-basiert), aber Option B ist eine gültige Alternative.

### Schritt 5: Dateien nach EC2 übertragen
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-5"></a>

Wählen Sie Ihre bevorzugte Dateiübertragungsmethode. In dieser Anleitung wird Amazon S3 als Beispiele verwendet.

**Amazon S3 verwenden:**

**Example Für Non-CDB:**  

```
# Copy files to Amazon S3 from the RDS Custom instance
aws s3 cp /rdsdbdata/backup s3://{{<YOUR_BUCKET>}}/ --recursive
aws s3 cp /tmp/initORCL.ora s3://{{<YOUR_BUCKET>}}/
aws s3 cp /rdsdbdata/config/orapwORCL s3://{{<YOUR_BUCKET>}}/

# On EC2, download files
aws s3 cp s3://{{<YOUR_BUCKET>}}/backup /u01/app/oracle/backup/ --recursive
aws s3 cp s3://{{<YOUR_BUCKET>}}/initORCL.ora $ORACLE_HOME/dbs/
aws s3 cp s3://{{<YOUR_BUCKET>}}/orapwORCL $ORACLE_HOME/dbs/
```

**Example Für Multitenant:**  

```
# Copy files to Amazon S3 from the RDS Custom instance
aws s3 cp /rdsdbdata/backup s3://{{<YOUR_BUCKET>}}/ --recursive
aws s3 cp /tmp/initRDSCDB.ora s3://{{<YOUR_BUCKET>}}/
aws s3 cp /rdsdbdata/config/orapwRDSCDB s3://{{<YOUR_BUCKET>}}/

# On EC2, download and rename files to use ORCL naming
aws s3 cp s3://{{<YOUR_BUCKET>}}/backup /u01/app/oracle/backup/ --recursive
aws s3 cp s3://{{<YOUR_BUCKET>}}/initRDSCDB.ora $ORACLE_HOME/dbs/initORCL.ora
aws s3 cp s3://{{<YOUR_BUCKET>}}/orapwRDSCDB $ORACLE_HOME/dbs/orapwORCL
```

### Schritt 6: Parameterdatei auf EC2 bearbeiten
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-6"></a>

Bearbeiten Sie `$ORACLE_HOME/dbs/initORCL.ora` die EC2-Instance und nehmen Sie die folgenden wichtigen Änderungen vor:

1. **Datenbanknamen aktualisieren**: Ändern Sie für Multitenant alle Vorkommen von in `RDSCDB` `ORCL`

1. **Ändern Sie db\_unique\_name**: Von (oder) zu `ORCL_A` `RDSCDB_A` `ORCL_B`

1. **Benutzerdefinierte RDS-Pfade in EC2-Pfade konvertieren**: Ersetzen durch `/rdsdbdata/` `/u01/app/oracle/`

1. 

****Custom-specific RDS-Parameter entfernen****
   + `dg_broker_config_file1`und `dg_broker_config_file2` (falls vorhanden)
   + `standby_file_management`(falls vorhanden)
   + `spfile`(wir werden `SPFILE` später ein neues erstellen)
   + Alle `log_archive_dest` Parameter, die auf Standby-Ziele verweisen

1. **Passen Sie die Speicherparameter** an Ihre EC2-Instance-Größe an (optional, aber empfohlen)

 **Pfadzuordnungen:** 

**Non-CDB:**
+ `/rdsdbdata/db/ORCL_A/datafile/` → `/u01/app/oracle/oradata/ORCL/datafile/`
+ `/rdsdbdata/db/ORCL_A/controlfile/` → `/u01/app/oracle/oradata/ORCL/controlfile/`
+ `/rdsdbdata/db/ORCL_A/onlinelog/` → `/u01/app/oracle/oradata/ORCL/onlinelog/`
+ `/rdsdbdata/admin/ORCL/adump` → `/u01/app/oracle/admin/ORCL/adump`

**Mehrmandantenfähig:**
+ `/rdsdbdata/db/cdb/RDSCDB/datafile/` → `/u01/app/oracle/oradata/ORCL/cdb/datafile/`
+ `/rdsdbdata/db/cdb/pdbseed/` → `/u01/app/oracle/oradata/ORCL/pdbseed/datafile/`
+ `/rdsdbdata/db/pdb/RDSCDB_A/` → `/u01/app/oracle/oradata/ORCL/pdb/datafile/`
+ `/rdsdbdata/db/cdb/RDSCDB_A/controlfile/` → `/u01/app/oracle/oradata/ORCL/controlfile/`
+ `/rdsdbdata/admin/RDSCDB/adump` → `/u01/app/oracle/admin/ORCL/adump`

**Wichtig**: Stellen Sie bei Multitenant sicher, dass `enable_pluggable_database` = in der Parameterdatei vorhanden `TRUE` ist.

### Schritt 7: Standby-Datenbank erstellen `SPFILE` und wiederherstellen
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-7"></a>

Starten Sie die Instanz und erstellen Sie SPFILE:

```
sqlplus / as sysdba
SQL> STARTUP NOMOUNT PFILE='$ORACLE_HOME/dbs/initORCL.ora';
SQL> CREATE SPFILE='/u01/app/oracle/admin/ORCL/pfile/spfileORCL.ora' FROM PFILE='$ORACLE_HOME/dbs/initORCL.ora';
SQL> SHUTDOWN IMMEDIATE;
```

Symbolischen Link erstellen:

```
ln -sfn /u01/app/oracle/admin/ORCL/pfile/spfileORCL.ora $ORACLE_HOME/dbs/spfileORCL.ora
```

Starten Sie die Instanz und stellen Sie sie wieder her:

```
SQL> STARTUP NOMOUNT;
rman target /
```

Wenn sich Backup-Dateien in einem anderen Pfad als der Quellpfad befinden, katalogisieren Sie sie zuerst:

```
RMAN> catalog start with '/u01/app/oracle/backup/';
```

Stellen Sie die Standby-Kontrolldatei wieder her und hängen Sie sie bereit:

```
RMAN> restore standby controlfile from '/u01/app/oracle/backup/standby.ctl';
RMAN> alter database mount;
```

Wenn sich die Pfade der Datendateien unterscheiden (z. B. bei Verwendung von ASM), verwenden Sie`SET NEWNAME`:

```
RMAN> run {
set newname for database to '+DATA/%b';
restore database;
switch datafile all;
}
```

Andernfalls stellen Sie einfach Folgendes wieder her:

```
RMAN> restore database;
```

Stellen Sie die Datenbank auf die letzte verfügbare Sequenz wieder her:

```
RMAN> list backup of archivelog all;
RMAN> recover database until sequence <LAST_SEQ + 1>;
```

**Anmerkung**  
Bei Mehrmandantenfähigkeit stellt RMAN automatisch alle PDBs wieder her und stellt sie wieder her. Sie müssen nicht jede PDB einzeln wiederherstellen.

### Schritt 8: TNS und Listener konfigurieren
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-8"></a>

Fügen Sie auf beiden Instanzen TNS-Einträge hinzu zu: `tnsnames.ora`

**Example Non-CDB:**  

```
ORCL_A = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<RDS_CUSTOM_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL)))
ORCL_B = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<EC2_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL)))
```

**Example Mehrmandantenfähig:**  

```
RDSCDB_A = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<RDS_CUSTOM_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = RDSCDB)))
ORCL_B = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<EC2_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL)))
```

Konfigurieren Sie Listener auf beiden Instanzen. Fügen Sie auf RDS Custom Folgendes hinzu: `listener.ora`

**Example Für Non-CDB:**  

```
SID_LIST_L_ORCL_DG=(SID_LIST = (SID_DESC = (SID_NAME = ORCL)(GLOBAL_DBNAME = ORCL) (ORACLE_HOME = /rdsdbbin/oracle.19.custom.r1.EE.1)))
L_ORCL_DG=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(PORT = 1521)(HOST = {{<RDS_CUSTOM_IP>}})))
```

**Example Für Multitenant:**  

```
SID_LIST_L_RDSCDB_DG=(SID_LIST = (SID_DESC = (SID_NAME = RDSCDB)(GLOBAL_DBNAME = RDSCDB) (ORACLE_HOME = /rdsdbbin/oracle.19.custom.r1.EE-CDB.1)))
L_RDSCDB_DG=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(PORT = 1521)(HOST = {{<RDS_CUSTOM_IP>}})))
```

Starten Sie den Listener:

```
$ORACLE_HOME/bin/lsnrctl start L_ORCL_DG # or L_RDSCDB_DG for multitenant
```

Erstellen Sie auf EC2: `$ORACLE_HOME/network/admin/listener.ora`

```
SID_LIST_L_ORCL_DG=(SID_LIST = (SID_DESC = (SID_NAME = ORCL)(GLOBAL_DBNAME = ORCL) (ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1)))
L_ORCL_DG=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(PORT = 1521)(HOST = {{<EC2_IP>}})))
```

Starten Sie den Listener:

```
$ORACLE_HOME/bin/lsnrctl start L_ORCL_DG
```

**Anmerkung**  
Sie können den vorhandenen Listener auf RDS Custom verwenden, falls Sie dies bevorzugen, aber die Erstellung eines separaten Data Guard-Listeners bietet eine bessere Isolierung.

**Wichtig**  
Wenn unsere `tnsping` `listener` Konnektivität fehlschlägt, überprüfen Sie die `iptables` Regeln auf EC2. Viele EC2-Linux-Instances haben `iptables` Standardregeln, die Port 1521 blockieren. Fügen Sie eine Regel hinzu: `sudo iptables -I INPUT 5 -p tcp --dport 1521 -j ACCEPT`

### Schritt 9: Aktivieren Sie den Data Guard Broker und die Konfiguration
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-9"></a>

Aktivieren Sie auf beiden Instanzen den Data Guard Broker:

```
sqlplus / as sysdba
SQL> ALTER SYSTEM SET dg_broker_start=true;
```

Stellen Sie auf dem RDS Custom Primary eine Verbindung zum Data Guard-Broker her und erstellen Sie die Konfiguration:

```
dgmgrl /
```

**Example Für Non-CDB:**  

```
DGMGRL> CREATE CONFIGURATION my_dg_config AS PRIMARY DATABASE IS ORCL_A CONNECT IDENTIFIER IS ORCL_A;
DGMGRL> ADD DATABASE ORCL_B AS CONNECT IDENTIFIER IS ORCL_B MAINTAINED AS PHYSICAL;
```

 

**Example Für Multitenant:**  

```
DGMGRL> CREATE CONFIGURATION my_dg_config AS PRIMARY DATABASE IS RDSCDB_A CONNECT IDENTIFIER IS RDSCDB_A;
DGMGRL> ADD DATABASE ORCL_B AS CONNECT IDENTIFIER IS ORCL_B MAINTAINED AS PHYSICAL;
```

Legen Sie statische Verbindungskennungen fest und aktivieren Sie:

 

**Example Für Non-CDB:**  

```
DGMGRL> edit database orcl_a set property StaticConnectIdentifier='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST=<RDS_CUSTOM_IP>))(CONNECT_DATA=(SID=ORCL)(SERVER=DEDICATED)))';
DGMGRL> edit database orcl_b set property StaticConnectIdentifier='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST={{<EC2_IP>}}))(CONNECT_DATA=(SID=ORCL)(SERVER=DEDICATED)))';
DGMGRL> ENABLE CONFIGURATION;
```

 

**Example Für Multitenant:**  

```
DGMGRL> edit database rdscdb_a set property StaticConnectIdentifier='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST=<RDS_CUSTOM_IP>))(CONNECT_DATA=(SID=RDSCDB)(SERVER=DEDICATED)))';
DGMGRL> edit database orcl_b set property StaticConnectIdentifier='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST={{<EC2_IP>}}))(CONNECT_DATA=(SID=ORCL)(SERVER=DEDICATED)))';
DGMGRL> ENABLE CONFIGURATION;
```

**Anmerkung**  
Der Data Guard Broker ist optional, wird aber für eine einfachere Verwaltung empfohlen. Für einfache Migrationen können Sie Data Guard manuell ohne den Broker konfigurieren.

**Anmerkung**  
Wenn Sie Data Guard für eine CDB aktivieren, schützt es automatisch alle PDBs. Von einem beliebigen PDB generiertes Redo wird an den Standby-Modus gesendet und auf den entsprechenden PDB im Standby-Modus angewendet.

### Schritt 10: Konfigurieren Sie die Standby-Redo-Logs und starten Sie die Wiederherstellung
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10"></a>

Fügen Sie auf der EC2-Standby-Instance Standby-Redo-Log-Dateien hinzu (n\+1, wobei n die Anzahl der Online-Redo-Log-Gruppen ist):

```
ALTER DATABASE ADD STANDBY LOGFILE ('slog1.rdo') SIZE 128M;
ALTER DATABASE ADD STANDBY LOGFILE ('slog2.rdo') SIZE 128M;
ALTER DATABASE ADD STANDBY LOGFILE ('slog3.rdo') SIZE 128M;
ALTER DATABASE ADD STANDBY LOGFILE ('slog4.rdo') SIZE 128M;
ALTER DATABASE ADD STANDBY LOGFILE ('slog5.rdo') SIZE 128M;
```

**Anmerkung**  
Bei Mehrmandantendiensten werden Standby-Redo-Logs auf CDB-Ebene erstellt und von allen PDBs gemeinsam genutzt.

Konfigurieren Sie die FAL-Parameter im Standby-Modus:

 

**Example Für Non-CDB:**  

```
SQL> alter system set fal_server = 'ORCL_A';
SQL> alter system set fal_client = 'ORCL_B';
```

 

**Example Für Multitenant:**  

```
SQL> alter system set fal_server = 'RDSCDB_A';
SQL> alter system set fal_client = 'ORCL_B';
```

Starten Sie die verwaltete Wiederherstellung:

```
SQL> recover managed standby database disconnect from session;
```

Überwachen Sie die Anwendungsverzögerung:

```
SQL> SELECT name, value FROM v$dataguard_stats WHERE name = 'apply lag';
```

**Detaillierte Überwachung und Verwaltung der Data Guard-Synchronisierung:**

Die Überwachung von Data Guard ist entscheidend für eine erfolgreiche Migration. Hier sind umfassende Überwachungstechniken:

1. **Überwachen Sie die Data Guard-Statistiken:**

   ```
   -- Comprehensive Data Guard statistics
   SQL> SELECT name, value, unit, time_computed, datum_time
   FROM v$dataguard_stats
   ORDER BY name;
   ```

   Wichtige zu überwachende Kennzahlen:
   + Transportverzögerung: Zeitunterschied zwischen dem Zeitpunkt, an dem die Wiederherstellung auf der Primärseite generiert wurde, und dem Zeitpunkt, zu dem die Wiederherstellung auf der Standby-Version empfangen wurde
   + Verzögerung anwenden: Zeitunterschied zwischen dem Zeitpunkt, an dem die Wiederherstellung generiert wurde, und dem Zeitpunkt, zu dem die Wiederherstellung im Standby-Modus ausgeführt wurde
   + Rate anwenden: Rate, mit der die Wiederherstellung angewendet wird () MB/sec
   + Wiederholung empfangen: Gesamtzahl der im Standby-Modus empfangenen Wiederholungen
   + Redo angewendet: Gesamter Redo-Vorgang, der vom Standby-Modus durchgeführt wurde

1. **Versand des Archivprotokolls überwachen:**

   Auf der Primärseite (RDS Custom):

   ```
   -- Check archive log generation rate
   SQL> SELECT TO_CHAR(first_time, 'YYYY-MM-DD HH24') AS hour,
          COUNT(*) AS log_count,
          ROUND(SUM(blocks * block_size)/1024/1024/1024, 2) AS size_gb
   FROM v$archived_log
   WHERE first_time > SYSDATE - 1
   GROUP BY TO_CHAR(first_time, 'YYYY-MM-DD HH24')
   ORDER BY hour;
   
   -- Check archive log destination status
   SQL> SELECT dest_id, status, error, destination
   FROM v$archive_dest
   WHERE status != 'INACTIVE';
   ```

   Im Standby-Modus (EC2):

   ```
   -- Check archive log apply status
   SQL> SELECT sequence#, first_time, next_time, applied
   FROM v$archived_log
   WHERE applied = 'NO'
   ORDER BY sequence#;
   
   -- Check archive log gap
   SQL> SELECT thread#, low_sequence#, high_sequence#
   FROM v$archive_gap;
   ```

1. **Überwachen Sie den verwalteten Wiederherstellungsprozess:**

   ```
   -- Check if managed recovery is running
   SQL> SELECT process, status, thread#, sequence#, block#, blocks
   FROM v$managed_standby
   WHERE process LIKE 'MRP%' OR process LIKE 'RFS%';
   
   -- Check recovery progress
   SQL> SELECT process, status, sequence#,
          TO_CHAR(timestamp, 'YYYY-MM-DD HH24:MI:SS') AS timestamp
   FROM v$managed_standby
   ORDER BY process;
   ```

1. **Überwachen Sie die Redo Apply-Rate für mehrere Mandanten:**

   Überwachen Sie bei Datenbanken mit mehreren Mandanten die Anwendungsrate pro PDB:

   ```
   -- Check redo apply rate per container
   SQL> SELECT con_id, name,
          ROUND(SUM(value)/1024/1024, 2) AS redo_applied_mb
   FROM v$con_sysstat cs, v$containers c
   WHERE cs.con_id = c.con_id
     AND cs.name = 'redo size'
   GROUP BY con_id, name
   ORDER BY con_id;
   ```

1. **Standby-Redo-Logs überwachen:**

   ```
   -- Check standby redo log status
   SQL> SELECT group#, thread#, sequence#, bytes/1024/1024 AS size_mb, status
   FROM v$standby_log
   ORDER BY group#;
   
   -- Check if standby redo logs are being used
   SQL> SELECT group#, thread#, sequence#, status, archived
   FROM v$standby_log
   WHERE status = 'ACTIVE';
   ```

1. **Voraussichtlicher Abschluss der Synchronisation:**

   Berechnen Sie die verbleibende Zeit auf der Grundlage der Anwendungsrate:

   ```
   -- Calculate estimated time to catch up
   SQL> SELECT
          ROUND((SELECT value FROM v$dataguard_stats WHERE name = 'apply lag')/60, 2) AS lag_minutes,
          ROUND((SELECT value FROM v$dataguard_stats WHERE name = 'apply rate')/1024, 2) AS apply_rate_mbps,
          ROUND(
            (SELECT value FROM v$dataguard_stats WHERE name = 'apply lag') /
            NULLIF((SELECT value FROM v$dataguard_stats WHERE name = 'apply rate'), 0) / 60,
            2
          ) AS estimated_catchup_minutes
   FROM dual;
   ```

#### Häufige Probleme mit der Data Guard-Synchronisierung:
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues"></a>



##### Problem 1: Hohe Anwendungsverzögerung
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-1"></a>

Symptome:

```
SQL> SELECT name, value FROM v$dataguard_stats WHERE name = 'apply lag';
NAME                             VALUE
-------------------------------- -----
apply lag                        +00 01:30:00
```

Ursachen und Lösungen:
+ **Nicht ausreichend CPU/IO im Standby-Modus**: Führen Sie ein Upgrade des EC2-Instance-Typs durch oder erhöhen Sie die EBS-IOPS
+ **Beschränkung der Netzwerkbandbreite**: Verwenden Sie Instance-Typen mit erweitertem Netzwerk oder höherer Bandbreite
+ **Mehrere PDBs mit hoher Transaktionsrate**: Erwägen Sie, die Redo-Apply-Parallelität zu erhöhen (erfordert eine Active Data Guard-Lizenz)

```
-- Increase apply parallelism (requires Active Data Guard)
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE PARALLEL 4 DISCONNECT FROM SESSION;
```

##### Problem 2: Lücke im Archivprotokoll
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-2"></a>

Symptome:

```
SQL> SELECT * FROM v$archive_gap;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
------- ------------- --------------
      1          1234           1240
```

Lösung:

```
-- FAL (Fetch Archive Log) will automatically fetch missing logs
-- Verify FAL parameters are set correctly
SQL> SHOW PARAMETER fal_server
SQL> SHOW PARAMETER fal_client

-- Manually register missing archive logs if needed
-- On primary, check if logs still exist
SQL> SELECT name FROM v$archived_log WHERE sequence# BETWEEN 1234 AND 1240;

-- If logs are missing on primary, you may need to rebuild the standby
```

##### Problem 3: Fehler beim Redo-Transport
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-3"></a>

Symptome:

```
SQL> SELECT dest_id, status, error FROM v$archive_dest WHERE dest_id = 2;
DEST_ID STATUS    ERROR
------- --------- ----------------------------------------
2       ERROR     ORA-16191: Primary log shipping client not logged on standby
```

Lösung:

```
-- Check network connectivity
-- Verify TNS configuration
-- Check listener status on standby
-- Restart log transport

SQL> ALTER SYSTEM SET log_archive_dest_state_2 = 'DEFER';
SQL> ALTER SYSTEM SET log_archive_dest_state_2 = 'ENABLE';
```

##### Problem 4: Bei der verwalteten Wiederherstellung wird Redo nicht angewendet
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-4"></a>

Symptome:

```
SQL> SELECT process, status FROM v$managed_standby WHERE process = 'MRP0';
PROCESS   STATUS
--------- ------------
MRP0      WAIT_FOR_LOG
```

Lösung:

```
# Check if archive logs are arriving
ls -ltr /u01/app/oracle/oradata/ORCL/arch/

# Check alert log for errors
tail -100 $ORACLE_BASE/diag/rdbms/orcl_b/ORCL/trace/alert_ORCL.log

# Restart managed recovery
sqlplus / as sysdba
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
```

**Bei Multitenant** können Sie auch den Status jeder PDB im Standby-Modus überprüfen:

```
SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs;
```

Erwartete Ausgabe (PDBs im `MOUNTED` Bereitschaftsmodus):

```
CON_ID     NAME                           OPEN_MODE  RES
---------- ------------------------------ ---------- ---
2          PDB$SEED                       MOUNTED
3          ORCLDB                         MOUNTED
```

**Anmerkung**  
Im physischen Standby-Modus bleiben die PDBs während der verwalteten `MOUNTED` Wiederherstellung im Status.

### Schritt 11: Führen Sie den Switchover durch
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-11"></a>

Wenn Sie sich davon überzeugt haben, dass der Standby-Modus vollständig synchronisiert und bereit ist, führen Sie den Switchover durch. Bei Mehrmandantenfähigkeit wird beim Switchover die gesamte CDB (alle PDBs) vom RDS-Custom-Primärmodus auf den EC2-Standby-Modus umgestellt.

Stellen Sie auf der primären RDS-Custom-Instance eine Verbindung zum Data Guard-Broker her und überprüfen Sie, ob beide Datenbanken für den Switchover bereit sind:

**Example Für Non-CDB:**  

```
DGMGRL> VALIDATE DATABASE ORCL_A;
DGMGRL> VALIDATE DATABASE ORCL_B;
```

 

**Example Für Multitenant:**  

```
DGMGRL> VALIDATE DATABASE RDSCDB_A;
DGMGRL> VALIDATE DATABASE ORCL_B;
```

Beides sollte angezeigt werden `Ready for Switchover: Yes`

Wechseln Sie vom RDS-Custom-Primärmodus zum EC2-Standby-Modus:

```
DGMGRL> SWITCHOVER TO ORCL_B;
```

Stellen Sie sicher, dass der Switchover erfolgreich ist:

```
DGMGRL> SHOW CONFIGURATION VERBOSE;
```

Die EC2-Instance (`ORCL_B`) ist jetzt die primäre Datenbank, und die RDS Custom Instance ist die physische Standby-Instance.

### Schritt 12: PDBs öffnen (nur für mehrere Mandanten)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-12"></a>

Nach dem Switchover ist die CDB auf EC2 im READ WRITE-Modus geöffnet, aber alle PDBs befinden sich im Status MOUNTED. Sie müssen sie manuell öffnen.

Connect zum neuen Primärserver auf EC2 her:

```
sqlplus / as sysdba
SQL> SELECT name, open_mode, database_role, cdb FROM v$database;
```

Erwartete Ausgabe:

```
NAME      OPEN_MODE            DATABASE_ROLE    CDB
--------- -------------------- ---------------- ---
ORCL      READ WRITE           PRIMARY          YES
```

Überprüfen Sie den aktuellen PDB-Status:

```
SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs;
```

Erwartete Ausgabe (PDBs im `MOUNTED` Status — Beispiel mit einer benannten PDB): `ORCLDB`

```
CON_ID     NAME                           OPEN_MODE  RES
---------- ------------------------------ ---------- ---
2          PDB$SEED                       READ ONLY  NO
3          ORCLDB                         MOUNTED
```

Alle PDBs öffnen:

```
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;
```

Die austauschbare Datenbank wurde geändert.

Stellen Sie sicher, dass alle PDBs jetzt im folgenden Modus geöffnet sind: `READ WRITE`

```
SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs;
```

Erwartete Ausgabe:

```
CON_ID     NAME                           OPEN_MODE  RES
---------- ------------------------------ ---------- ---
2          PDB$SEED                       READ ONLY  NO
3          ORCLDB                         READ WRITE NO
```

### Schritt 13: Automatisches Öffnen von PDB beim Start konfigurieren (nur Multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-13"></a>

Konfigurieren Sie PDBs mithilfe der Save-State-Methode so, dass sie beim Start der CDB automatisch geöffnet werden (empfohlen für Oracle 19c):

```
SQL> ALTER PLUGGABLE DATABASE ALL SAVE STATE;
Pluggable database altered.
```

Überprüfen Sie den gespeicherten Status:

```
SQL> SELECT con_name, instance_name, state FROM dba_pdb_saved_states;
```

Stellen Sie sicher, dass die PDB-Dienste beim Listener registriert sind:

```
lsnrctl services
```

Die erwartete Ausgabe sollte Dienste für die CDB und jede PDB enthalten. Wenn Dienste nicht angezeigt werden:

```
SQL> ALTER SYSTEM REGISTER;
```

Dann überprüfen Sie erneut mit`lsnrctl services`.

### Schritt 14: Entfernen Sie benutzerdefinierte RDS-Objekte
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-14"></a>

Da es sich jetzt um eine selbstverwaltete Datenbank auf EC2 handelt, sollten Sie RDS Custom-spezifische Benutzer und Objekte entfernen. Der Bereinigungsprozess unterscheidet sich geringfügig zwischen Nicht-CDB- und Mehrmandantenarchitekturen.

**Wichtig**  
Bevor Sie RDS-specific Benutzer und Tablespaces löschen, stellen Sie sicher, dass keine Anwendungsobjekte unter diesen Schemas existieren:

```
SQL> SELECT owner, object_type, COUNT(*)
FROM dba_objects
WHERE owner IN ('RDSADMIN', 'RDS_DATAGUARD')
  AND object_name NOT LIKE 'RDS%'
  AND object_name NOT LIKE 'SYS_%'
GROUP BY owner, object_type;
```

Wenn Anwendungsobjekte gefunden werden, migrieren Sie sie in die entsprechenden Anwendungsschemas, bevor Sie fortfahren.

**Non-CDB Säuberung:**

```
sqlplus / as sysdba

-- Drop RDS-specific users
SQL> DROP USER RDSADMIN CASCADE;
SQL> DROP USER RDS_DATAGUARD CASCADE;

-- Drop RDS-specific directories
SQL> DROP DIRECTORY OPATCH_INST_DIR;
SQL> DROP DIRECTORY OPATCH_LOG_DIR;
SQL> DROP DIRECTORY OPATCH_SCRIPT_DIR;

-- Drop the RDSADMIN tablespace
SQL> DROP TABLESPACE RDSADMIN INCLUDING CONTENTS AND DATAFILES;

-- Verify removal
SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%';
```

Erwartete Leistung: `no rows selected`

**Bereinigung für mehrere Mandanten:**

In einer Umgebung mit mehreren Mandanten erstellt RDS Custom gemeinsame Benutzer, `CDB$ROOT` die in allen PDBs sichtbar sind. Sie müssen aufräumen von. `CDB$ROOT`

```
sqlplus / as sysdba

-- Verify you are in CDB$ROOT
SQL> SHOW CON_NAME;

-- Check for RDS-specific common users (including C## prefixed users)
SQL> SELECT username, common, con_id FROM cdb_users
WHERE username LIKE 'RDS%' OR username LIKE 'C##RDS%'
ORDER BY username;

-- Drop non-common users
SQL> DROP USER RDSADMIN CASCADE;
SQL> DROP USER RDS_DATAGUARD CASCADE;

-- If any C## common users exist
-- Example (adjust based on your findings):
-- SQL> DROP USER C##RDS_DATAGUARD CASCADE;
-- Drop RDS-specific directories
SQL> DROP DIRECTORY OPATCH_INST_DIR;
SQL> DROP DIRECTORY OPATCH_LOG_DIR;
SQL> DROP DIRECTORY OPATCH_SCRIPT_DIR;

-- Drop the RDSADMIN tablespace
SQL> DROP TABLESPACE RDSADMIN INCLUDING CONTENTS AND DATAFILES;

-- Verify removal from CDB$ROOT
SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%';

-- Verify removal from each PDB (example with one PDB named ORCLDB)
SQL> ALTER SESSION SET CONTAINER = ORCLDB;
SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%';
```

Erwartete Ausgabe für alle Abfragen: Es wurden keine Zeilen ausgewählt

### Schritt 15: Konfigurieren Sie den automatischen Start
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-15"></a>

Stellen Sie sicher, `SPFILE` dass das verwendet wird:

```
sqlplus / as sysdba
SQL> SHOW PARAMETER spfile;
```

Wenn der `spfile` Pfad korrekt ist, ist keine Aktion erforderlich. Wenn nicht, erstelle einen:

```
SQL> CREATE SPFILE FROM MEMORY;
```

Starten Sie die Datenbank neu:

```
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;
```

Öffnen Sie für Multitenant alle PDBs (sie sollten sich automatisch öffnen, wenn Sie den Status zuvor gespeichert haben):

```
SQL> SELECT con_id, name, open_mode FROM v$pdbs;
```

Wenn PDBs nicht geöffnet sind, öffnen Sie sie manuell:

```
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;
```

Bearbeiten`/etc/oratab`:

```
vi /etc/oratab
```

Ändern Sie die Zeile für `ORCL` von `N` zu`Y`:

```
ORCL:/u01/app/oracle/product/19.0.0/dbhome_1:Y
```

### Schritt 16: Endgültige Validierung
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-16"></a>

Führen Sie eine umfassende Validierung der migrierten Datenbank durch.

**Example Für Non-CDB:**  

```
sqlplus / as sysdba

-- Verify database role and status
SQL> SELECT name, open_mode, log_mode, database_role FROM v$database;

-- Check database size
SQL> SELECT SUM(bytes)/1024/1024/1024 AS size_gb FROM dba_data_files;

-- Verify all objects are valid
SQL> SELECT owner, object_type, COUNT(*)
     FROM dba_objects
     WHERE status = 'INVALID'
     GROUP BY owner, object_type;

-- Verify data files
SQL> SELECT name, status FROM v$datafile;

-- Test application connectivity
SQL> SELECT username, machine, program FROM v$session WHERE username IS NOT NULL;
```

**Example Für Multitenant:**  

```
sqlplus / as sysdba

-- Verify CDB status
SQL> SELECT name, open_mode, log_mode, cdb, database_role FROM v$database;

-- Verify all PDBs are open
SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs;

-- Check total CDB size
SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM cdb_data_files;

-- Check size per PDB
SQL> SELECT p.name AS pdb_name,
       ROUND(SUM(d.bytes)/1024/1024/1024, 2) AS size_gb
FROM v$pdbs p
JOIN cdb_data_files d ON p.con_id = d.con_id
GROUP BY p.name,p.con_id
ORDER BY p.con_id;

-- Verify all objects are valid across all PDBs
SQL> SELECT con_id, owner, object_type, COUNT(*)
     FROM cdb_objects
     WHERE status = 'INVALID'
     GROUP BY con_id, owner, object_type;

-- Verify PDB services are registered
SQL> SELECT name FROM v$services ORDER BY name;

Test application connectivity:

# Non-CDB
sqlplus {{<app_user>}}/{{<password>}}@{{<EC2_IP>}}:1521/ORCL

# Multitenant (connect to PDB)
sqlplus {{<app_user>}}/{{<password>}}@{{<EC2_IP}}>:1521/{{<PDB_NAME>}}
```

Testen Sie die Anwendungskonnektivität:

```
# Non-CDB
sqlplus {{<app_user>}}/{{<password>}}@{{<EC2_IP>}}:1521/ORCL

# Multitenant (connect to PDB)
sqlplus {{<app_user>}}/{{<password>}}@{{<EC2_IP>}}:1521/{{<PDB_NAME>}}
```

### Schritt 17: Backup-Dateien bereinigen
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-17"></a>

Entfernen Sie nach erfolgreicher Überprüfung die Sicherungsdateien und trennen Sie das Backup-Volume, wenn Sie ein separates EBS-Volume verwenden:

```
rm -rf /u01/app/oracle/backup/*
```

Wenn Sie ein separates EBS-Volume für Backups verwenden:

```
# Unmount the volume
sudo umount /u01/app/oracle/backup

# Detach and delete the EBS volume from AWS Console or CLI
aws ec2 detach-volume --volume-id {{<volume-id>}}
aws ec2 delete-volume --volume-id {{<volume-id>}}
```

### Schritt 18: Setzen Sie die benutzerdefinierte RDS-Automatisierung fort
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-18"></a>

Wenn Sie planen, die RDS Custom-Instance während eines Validierungszeitraums als Fallback weiterlaufen zu lassen, setzen Sie die Automatisierung fort:

```
aws rds modify-db-instance \
  --db-instance-identifier my-custom-instance \
  --automation-mode full \
  --region us-east-1
```

## Behebung häufiger Probleme
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting"></a>



In diesem Abschnitt werden häufig auftretende Probleme behandelt, die bei der Migration sowohl bei der RMAN-Duplizierung als auch bei Oracle Data Guard-Ansätzen auftreten können. Dabei werden sowohl Nicht-CDB- als auch Mehrmandantenarchitekturen behandelt.

### ORA-09925: Die Audit-Trail-Datei konnte nicht erstellt werden
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-09925"></a>

**Ursache:** Das im `audit_file_dest` Parameter angegebene Auditverzeichnis ist auf der EC2-Zielinstanz nicht vorhanden.

 **Lösung:** 

Stellen Sie sicher, dass das Audit-Verzeichnis vorhanden ist und über die erforderlichen Berechtigungen verfügt:

```
mkdir -p /u01/app/oracle/admin/ORCL/adump
chown -R oracle:oinstall /u01/app/oracle/admin/ORCL
chmod -R 755 /u01/app/oracle/admin/ORCL
```

### ORA-01261: Die `db_create_file_dest` Zielzeichenfolge des Parameters kann nicht übersetzt werden
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-01261"></a>

**Ursache:** Das im `db_create_file_dest` Parameter angegebene Verzeichnis ist auf der EC2-Zielinstanz nicht vorhanden.

 **Lösung:** 

Für Nicht-CDB:

```
mkdir -p /u01/app/oracle/oradata/ORCL
chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL
chmod -R 755 /u01/app/oracle/oradata/ORCL
```

Für Mehrmandantenfähigkeit:

```
mkdir -p /u01/app/oracle/oradata/ORCL/pdb/datafile
chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL
chmod -R 755 /u01/app/oracle/oradata/ORCL
```

### ORA-01804: Fehler beim Initialisieren der Zeitzoneninformationen
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-01804"></a>

Dieser Fehler kann auftreten, wenn der `RDSADMIN` Benutzer gelöscht wird, wenn die RDS-Quelle eine höhere Zeitzonenversion hat als die, die in Ihrem EC2 $ORACLE\_HOME installiert ist.

 **Lösung:** 

1. Überprüfen Sie die Zeitzonen-Versionen:

   ```
   SELECT * FROM v$timezone_file;
   SELECT PROPERTY_NAME, PROPERTY_VALUE
   FROM database_properties
   WHERE PROPERTY_NAME LIKE '%DST%';
   ```

1. Um das Problem zu umgehen, stellen Sie die Umgebungsvariable für die Zeitzonendatei so ein, dass sie dem entspricht, was in $ORACLE\_HOME verfügbar ist:

   ```
   ls $ORACLE_HOME/oracore/zoneinfo/timezlrg_*.dat
   export ORA_TZFILE=$ORACLE_HOME/oracore/zoneinfo/timezone_40.dat
   ```

   Passen Sie die Nummer so an, dass sie der in Ihrer Installation verfügbaren Version entspricht.

1. Versuchen Sie es erneut mit dem Drop:

   ```
   sqlplus / as sysdba
   SQL> DROP USER RDSADMIN CASCADE;
   ```

### Cross-RU Migrationsprobleme (verschiedene Release-Updates)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-cross-ru-migration"></a>

**Ursache:** Die EC2-Zielinstanz hat ein anderes Oracle Release Update (RU) oder einmalige Patches als die benutzerdefinierte RDS-Quellinstanz, was während oder nach der Migration zu Kompatibilitätsfehlern führt.

**Häufige Fehler:**
+ ORA-00600 Bei der Wiederherstellung treten interne Fehler auf (Data Guard)
+ ORA-39700 Die Datenbank muss mit `UPGRADE` der Option geöffnet werden
+ Wörterbuchinkonsistenzen nach der Migration
+ Ungültige Objekte in oder `DBA_REGISTRY` `DBA_OBJECTS`

 **Lösung:** 

 **Bewährtes Verfahren — Ordnen Sie RU-Versionen und einmalige Patches exakt zu:** 

1. Überprüfen Sie die genaue RU-Version sowohl für die Quelle als auch für das Ziel:

   ```
   -- On both source and target
   SQL> SELECT * FROM v$version;
   
   SQL> SELECT patch_id, patch_uid, version, action, status, description
   FROM dba_registry_sqlpatch
   ORDER BY action_time DESC;
   ```

1. Überprüfen Sie das $ORACLE\_HOME-Patch-Level:

   ```
   # On both instances
   $ORACLE_HOME/OPatch/opatch lsinventory
   ```

1. Wenn die Versionen nicht übereinstimmen, passen Sie sie vor der Migration an, indem Sie nach Bedarf Patches anwenden oder rückgängig machen.

1. Wenn Sie mit nicht übereinstimmenden RUs fortfahren müssen, führen Sie Datapatch nach der Migration aus:

   ```
   cd $ORACLE_HOME/OPatch
   ./datapatch -verbose
   ```

1. Suchen Sie nach ungültigen Objekten und kompilieren Sie erneut:

   ```
   SQL> @?/rdbms/admin/utlrp.sql
   
   SQL> SELECT owner, object_type, COUNT(*)
   FROM dba_objects
   WHERE status = 'INVALID'
   GROUP BY owner, object_type;
   ```

### Probleme mit der Netzwerkkonnektivität
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-network-connectivity"></a>

 

**Ursache:** Sicherheitsgruppen, Netzwerk-ACLs oder `iptables` Blockierung des Oracle-Listener-Ports.

 **Lösung:** 

1. Stellen Sie sicher, dass Sicherheitsgruppen den Port bidirektional zulassen

1. Überprüfen Sie iptables auf EC2:

   ```
   sudo iptables -L INPUT -n -v
   ```

1. Regel hinzufügen, falls erforderlich:

   ```
   # Insert rule before the REJECT rule (typically position 5)
   sudo iptables -I INPUT 5 -p tcp --dport 1521 -j ACCEPT
   
   # For enhanced security, allow only from specific source IPs
   sudo iptables -I INPUT 5 -p tcp -s {{<RDS_Custom_IP>}} --dport 1521 -j ACCEPT
   
   # Save rules permanently
   sudo service iptables save
   ```

1. Konnektivität testen:

   ```
   telnet {{<EC2_instance_IP>}} 1521
   tnsping DB_SOURCE
   tnsping DB_TARGET
   ```

### PDBs werden nach der Migration nicht geöffnet (nur für mehrere Mandanten)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdbs-not-opening"></a>

**Ursache:** Dies ist das erwartete Verhalten. Nach der RMAN-Duplizierung oder dem Data Guard-Switchover ist die CDB geöffnet, aber die PDBs befinden sich im Status. `MOUNTED`

 **Lösung:** 

Öffnen Sie sie manuell:

```
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;
```

Wenn eine bestimmte PDB nicht geöffnet werden kann, überprüfen Sie das Warnungsprotokoll auf Fehler:

```
tail -100 $ORACLE_BASE/diag/rdbms/orcl/ORCL/trace/alert_ORCL.log
```

Zu den häufigsten Ursachen gehören fehlende Datendateien oder Probleme mit der Pfadzuordnung.

### PDB-Datendateien wurden nicht gefunden oder der Pfad stimmt nicht überein (nur für mehrere Mandanten)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdb-data-files-not-found"></a>

**Ursache:** Bei der Migration wurden nicht alle Quellpfade korrekt zugeordnet, insbesondere bei OMF-based PDB-Datendateien.

 **Lösung:** 

1. Überprüfen Sie, welche Datendateien fehlen:

   ```
   SQL> SELECT name, status FROM v$datafile WHERE status != 'ONLINE';
   ```

1. Wenn die Dateien im falschen Verzeichnis abgelegt wurden, benennen Sie sie in der Steuerdatei um:

   ```
   SQL> ALTER DATABASE RENAME FILE '/wrong/path/datafile.dbf' TO '/correct/path/datafile.dbf';
   ```

1. Um dies zu verhindern, überprüfen Sie immer die Pfade der Quelldatendateien mit, `SELECT con_id, name FROM v$datafile ORDER BY con_id;` bevor Sie die Parameterdatei konfigurieren.

### PDB-Dienste registrieren sich nicht beim Listener (nur für mehrere Mandanten)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdb-services-not-registering"></a>

**Ursache:** Der Listener kennt die PDB-Dienste nach dem Öffnen von PDBs nicht.

 **Lösung:** 

1. Registrierung des Dienstes erzwingen:

   ```
   SQL> ALTER SYSTEM REGISTER;
   ```

1. Wenn Dienste immer noch nicht angezeigt werden, überprüfen Sie den `local_listener` Parameter:

   ```
   SQL> SHOW PARAMETER local_listener;
   ```

   Stellen Sie sicher, dass er auf die richtige Listener-Adresse verweist. Falls erforderlich, aktualisieren Sie es:

   ```
   SQL> ALTER SYSTEM SET local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST={{<EC2_instance_IP>}})(PORT=1521))';
   SQL> ALTER SYSTEM REGISTER;
   ```

1. Verifizieren Sie mit:

   ```
   lsnrctl services
   ```

### PDBs werden nach dem CDB-Neustart nicht automatisch geöffnet (nur Multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdbs-not-opening-after-cdb-restart"></a>

**Ursache:** Der PDB-Speicherstatus wurde nicht konfiguriert.

 **Lösung:** 

Stellen Sie sicher, dass der PDB-Speicherstatus konfiguriert wurde:

```
SQL> SELECT con_name, instance_name, state FROM dba_pdb_saved_states;
```

Wenn keine Zeilen zurückgegeben werden, speichern Sie den Status:

```
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;
SQL> ALTER PLUGGABLE DATABASE ALL SAVE STATE;
```

### Data Guard Redo Transport funktioniert nicht
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-odg-redo-transport-failure"></a>

**Ursache:** Probleme mit der Netzwerkverbindung, falsche TNS-Konfiguration oder nicht festgelegte FAL-Parameter.

 **Lösung:** 

1. Stellen Sie sicher, dass sich der Standby-Modus im MOUNT-Modus befindet:

   ```
   SQL> SELECT status FROM v$instance;
   ```

1. Prüfen Sie, ob fal\_server und fal\_client im Standby-Modus korrekt eingestellt sind:

   ```
   SQL> SHOW PARAMETER fal_server
   SQL> SHOW PARAMETER fal_client
   ```

1. Überprüfen Sie die Netzwerkkonnektivität:

   ```
   tnsping ORCL_A # or RDSCDB_A for multitenant
   ```

1. Überprüfen Sie den Parameter log\_archive\_dest\_2 an den primären Bereitschaftspunkten (falls manuell ohne Broker konfiguriert).

 **Data Guard wendet bei mehreren PDBs zunehmende Verzögerungen an (nur für mehrere Mandanten)** 

**Ursache:** Bei CDBs mit mehreren PDBs kann das Redo Apply-Verfahren aufgrund des Umfangs der Änderungen in allen Containern langsamer sein.

 **Lösung:** 

1. Überprüfen Sie die Anwendungsrate:

   ```
   SQL> SELECT name, value, unit FROM v$dataguard_stats WHERE name IN ('apply rate', 'apply lag');
   ```

1. Erwägen Sie, die Parallelität für Redo Apply zu erhöhen (erfordert eine Active Data Guard-Lizenz):

   ```
   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE PARALLEL 4 DISCONNECT FROM SESSION;
   ```

1. Stellen Sie sicher, dass auf der Standby-Instanz keine Ressourcenbeschränkungen (CPU, I/O) bestehen.

 **Die Sicherung des RMAN-Archivprotokolls schlägt fehl mit ORA-19625** 

**Ursache:** RDS Custom Automation hat ältere Archivprotokolle von der Festplatte gelöscht, aber die RMAN-Steuerdatei enthält immer noch Aufzeichnungen davon.

 **Lösung:** 

1. Überprüfen und bereinigen Sie veraltete Archivprotokolleinträge:

   ```
   RMAN> CROSSCHECK ARCHIVELOG ALL;
   RMAN> DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;
   ```

1. Re-run nur die Archiv-Log-Backup:

   ```
   RMAN> RUN {
   SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
   BACKUP AS COMPRESSED BACKUPSET
   FILESPERSET 50
   FORMAT '/rdsdbdata/backup/arch_%U'
   ARCHIVELOG ALL;
   }
   ```

### Häufig schlägt das Löschen von Benutzern bei Multitenant fehl (nur Multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-multitenant-user-drop-fails"></a>

 

**Ursache:** Allgemeine Benutzer (mit dem Präfix C\#\#) müssen mit der Klausel gelöscht werden. `CONTAINER=ALL`

 **Lösung:** 

```
-- For common users
SQL> DROP USER C##RDS_DATAGUARD CASCADE CONTAINER=ALL;

-- For non-common users in CDB$ROOT
SQL> DROP USER RDSADMIN CASCADE;
```

Stellen Sie sicher, dass Sie verbunden sind mit: `CDB$ROOT`

```
SQL> SHOW CON_NAME;
```

## Post-migration Aufgaben
<a name="RDS-Custom-for-Oracle-end-of-support-post-migration"></a>

Führen Sie nach erfolgreicher Migration diese zusätzlichen Aufgaben aus, um sicherzustellen, dass Ihre selbstverwaltete Oracle-Datenbank auf EC2 produktionsbereit ist.

 **Aktualisieren Sie die Verbindungszeichenfolgen für die Anwendung** 

**Für Non-CDB:**
+ Verweisen Sie Ihre Anwendungen auf den neuen EC2-Instance-Endpunkt
+ Aktualisieren Sie die Verbindungszeichenfolgen, sodass sie die IP oder den Hostnamen der EC2-Instanz verwenden
+ Testen Sie die gesamte Anwendungsfunktionalität gründlich

**Für Multitenant:**
+ Verweisen Sie Ihre Anwendungen auf die PDB-Dienstnamen der neuen EC2-Instance (z. B. ORCLDB oder Ihre spezifischen PDB-Namen)
+ Stellen Sie sicher, dass Anwendungen eine Verbindung zur richtigen PDB herstellen, nicht mit der CDB
+ Aktualisieren Sie die Verbindungszeichenfolgen, um PDB-Dienstnamen zu verwenden
+ Testen Sie die gesamte Anwendungsfunktionalität für jede PDB

Beispiele für Verbindungszeichenfolgen:

```
# Non-CDB
jdbc:oracle:thin:@{{<EC2_IP>}}:1521/ORCL

# Multitenant (connect to PDB)
jdbc:oracle:thin:@{{<EC2_IP>}}:1521/ORCLDB
```

 **Backup-Strategie konfigurieren** 

Richten Sie eine umfassende Backup-Strategie für Ihre selbstverwaltete Datenbank ein:

**RMAN-Backups:**
+ Konfigurieren Sie automatisierte RMAN-Backup-Skripten für vollständige, inkrementelle und archivierte Log-Backups
+ Richten Sie Richtlinien zur Aufbewahrung von Backups auf der Grundlage Ihrer Recovery Point Objectives (RPO) ein
+ Speichern Sie Backups auf Amazon S3, um Haltbarkeit und Wirtschaftlichkeit zu gewährleisten
+ Testen Sie regelmäßig die Verfahren zur Wiederherstellung von Backups

**AWS Backup:**
+ [AWS Backup](https://aws.amazon.com/backup/)Für EBS-Volume-Snapshots verwenden
+ Konfigurieren Sie Backup-Zeitpläne und Aufbewahrungsrichtlinien
+ Aktivieren Sie regionsübergreifende Sicherungskopien für die Notfallwiederherstellung

**Für Multitenant:**
+ RMAN-Backups der CDB enthalten automatisch alle PDBs
+ Sie können bei Bedarf auch einzelne PDBs sichern
+ Ziehen Sie PDB-specific Backup-Zeitpläne in Betracht, die auf den Geschäftsanforderungen basieren

Beispiel für ein RMAN-Backup-Skript:

```
#!/bin/bash
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
export ORACLE_SID=ORCL
export PATH=$ORACLE_HOME/bin:$PATH
rman target / << EOF
run {
  backup as compressed backupset database plus archivelog;
  delete noprompt obsolete;
}
exit;
EOF
```

 **Überwachung einrichten** 

Implementieren Sie eine umfassende Überwachung für Ihre EC2-hosted Oracle-Datenbank:

**Amazon CloudWatch**
+ Richten Sie CloudWatch Metriken für den Zustand der EC2-Instance, die Festplattennutzung und benutzerdefinierte Oracle-Metriken ein
+ Erstellen Sie CloudWatch Alarme für kritische Schwellenwerte
+ Verwenden Sie CloudWatch Logs für die Überwachung von Datenbank-Warnungsprotokollen

**Oracle Enterprise Manager (OEM):**
+ Falls verfügbar, konfigurieren Sie OEM für die Datenbanküberwachung
+ Richten Sie Leistungsüberwachung und Diagnose ein
+ Konfigurieren Sie automatische Benachrichtigungen für kritische Ereignisse

**Third-party Tools:**
+ Ziehen Sie Tools wie Datadog, New Relic oder Prometheus für die Datenbanküberwachung in Betracht
+ Integrieren Sie es in Ihre bestehende Monitoring-Infrastruktur

**Wichtige zu überwachende Kennzahlen:**
+ Tablespace-Nutzung
+ Log-Speicherplatz archivieren
+ Ungültige Objekte
+ Die Anzahl der Sitzungen
+ Warteereignisse
+ CPU- und Speicherauslastung
+ I/O Leistung

**Für Multitenant:**
+ Überwachen Sie beides CDB-level und Metriken PDB-level 
+ Richten Sie Benachrichtigungen für die Nutzung und Kontingente von PDB-Ressourcen ein
+ Verfolgen Sie PDB-specific Leistungskennzahlen

 **Konfigurieren Sie Sicherheitsgruppen und Netzwerk-ACLs** 

Überprüfen und verschärfen Sie die Sicherheit für die EC2-Instance:

**Sicherheitsgruppen:**
+ Beschränken Sie den Zugriff auf Datenbankports nur auf autorisierte Anwendungsserver und Bastion-Hosts
+ Entfernen Sie alle übermäßig freizügigen Regeln, die während der Migration erstellt wurden
+ Dokumentieren Sie die Regeln für Sicherheitsgruppen und ihre Zwecke

**Netzwerk-ACLs:**
+ Konfiguration von VPC-Netzwerk-ACLs für zusätzliche Sicherheitsebenen
+ Implementieren Sie eine umfassende Sicherheitsstrategie

**SSH-Zugriff:**
+ Beschränken Sie den SSH-Zugriff auf bestimmte IP-Bereiche oder verwenden Sie AWS Systems Manager Session Manager
+ Deaktivieren Sie die Kennwortauthentifizierung und verwenden Sie nur die schlüsselbasierte Authentifizierung
+ Implementieren Sie die Multi-Faktor-Authentifizierung (MFA) für privilegierten Zugriff

**Verschlüsselung:**
+ Aktivieren Sie die Verschlüsselung im Ruhezustand für EBS-Volumes
+ Aktivieren Sie die Verschlüsselung während der Übertragung für Datenbankverbindungen mit Oracle Native Network Encryption oder TLS
+ Wechseln Sie die Verschlüsselungsschlüssel regelmäßig

**Implementieren Sie Hochverfügbarkeit**

Wenn Ihr Workload eine hohe Verfügbarkeit erfordert, sollten Sie die Implementierung von Folgendem in Betracht ziehen:

**Oracle Data Guard:**
+ Konfigurieren Sie eine neue Standby-Datenbank auf einer anderen EC2-Instance für Disaster Recovery
+ Bei Mehrmandantenfähigkeit schützt Data Guard die gesamte CDB, einschließlich aller PDBs
+ Der Standby-Modus kann sich in einer anderen Availability Zone oder Region befinden
+ Implementieren Sie automatisierte Failover-Mechanismen mithilfe von Skripten oder Tools von Drittanbietern

**AWS Multi-AZ Bereitstellung:**
+ Bereitstellen von Standby-Instanzen in verschiedenen Availability Zones
+ Verwenden Sie Amazon Route 53 für DNS-Failover
+ Implementieren Sie Verbindungspooling auf Anwendungsebene mit Failover-Unterstützung

**Backup und Wiederherstellung:**
+ Sorgen Sie mit getesteten Wiederherstellungsverfahren für regelmäßige Backups
+ Dokumentieren Sie Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO)
+ Führen Sie regelmäßige Notfallwiederherstellungsübungen durch

**Führen Sie gründliche Anwendungstests durch**

Vor der Außerbetriebnahme der RDS Custom-Instanz:

**Funktionstests:**
+ Stellen Sie sicher, dass alle Anwendungsfunktionen ordnungsgemäß funktionieren
+ Testen Sie alle datenbankabhängigen Funktionen
+ Überprüfen Sie die Datenintegrität und -konsistenz

**Leistungstests:**
+ Vergleichen Sie Leistungskennzahlen mit der RDS-Baseline für Custom
+ Identifizieren und beheben Sie etwaige Leistungseinbußen
+ Optimieren Sie Abfragen und Indizes nach Bedarf

**Belastungstests:**
+ Testen Sie die Datenbank bei erwarteten Spitzenlasten
+ Stellen Sie sicher, dass die Ressourcennutzung innerhalb akzeptabler Grenzen bleibt
+ Identifizieren und beheben Sie etwaige Engpässe

**Failover-Tests (falls HA konfiguriert ist):**
+ Testen Sie Failover-Szenarien
+ Überprüfen Sie die Logik für die Wiederherstellung der Verbindung von Anwendungen
+ Messen Sie den tatsächlichen RTO und RPO

**Testen von Backup und Wiederherstellungen:**
+ Stellen Sie sicher, dass die Sicherungs- und Wiederherstellungsverfahren ordnungsgemäß funktionieren
+ Testen Sie die Wiederherstellung zu einem bestimmten Zeitpunkt
+ Überprüfen Sie die Integrität des Backups

**Für Multitenant:**
+ Testen Sie jede PDB unabhängig
+ Überprüfen Sie die PDB-Isolierung und die Ressourcenzuweisung
+  PDB-specific Testvorgänge ( unplug/plugKlonen usw.)

**Setzen Sie die benutzerdefinierte RDS-Instanz außer Betrieb**

Nach einem erfolgreichen Validierungszeitraum (in der Regel 1—2 Wochen):

1. **Endgültiges Backup: Erstellen** Sie zu Archivierungszwecken ein letztes Backup der RDS Custom-Instance

   ```
   # Create final snapshot
   aws rds create-db-snapshot \
     --db-instance-identifier my-custom-instance \
     --db-snapshot-identifier my-custom-instance-final-snapshot \
     --region us-east-1
   ```

1. **Dokumentieren Sie die Migration**: Aktualisieren Sie Runbooks und Dokumentation mit der neuen EC2-Konfiguration

1. **Löschen Sie die benutzerdefinierte RDS-Instanz**: Verwenden Sie die AWS Konsole oder CLI, um die Instanz zu löschen

   ```
   # Delete RDS Custom instance without final snapshot (if already created above)
   aws rds delete-db-instance \
     --db-instance-identifier my-custom-instance \
     --skip-final-snapshot \
     --region us-east-1
   
   # Or create a final snapshot before deletion
   aws rds delete-db-instance \
     --db-instance-identifier my-custom-instance \
     --final-db-snapshot-identifier my-custom-instance-final-snapshot \
     --region us-east-1
   ```

1. **Ressourcen bereinigen**: Entfernen Sie die zugehörigen Snapshots, Parametergruppen und Optionsgruppen, wenn sie nicht mehr benötigt werden

1. **Dokumentation aktualisieren**: Stellen Sie sicher, dass die gesamte Betriebsdokumentation die neue EC2-based Architektur widerspiegelt

## Vergleich: RMAN Active Duplication im Vergleich zu Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-RMAN-vs-ODG"></a>

In der folgenden Tabelle sind die wichtigsten Unterschiede zwischen den beiden Migrationsoptionen zusammengefasst:


|  **Aspekt**  |  **Aktive RMAN-Duplizierung**  |  **Oracle Data Guard**  | 
| --- | --- | --- | 
| **Verfügbarkeit der Quelldatenbank** | Online während der gesamten Vervielfältigung | Während des gesamten Vorgangs online | 
| **Ausfallzeit** | Minuten (nur endgültige Umstellung) | Sekunden bis Minuten (Umstellung) | 
| **Komplexität** | Niedriger | Höher | 
| **Dauer der Migration** | Einzelner Duplizierungsvorgang | Ersteinrichtung \+ kontinuierliche Synchronisierung | 
| **Kontinuierliche Synchronisation** | Nein | Ja | 
| **Fallback-Fähigkeit** | Manuell (Quelle am Laufen lassen) | Built-in (automatisch) | 
| **Testen vor der Umstellung** | Eingeschränkt (Test nach der Vervielfältigung) | Vollständiger Test möglich (Standby kann getestet werden) | 
| **Netzwerk-Bandbreite** | Hoch beim Duplizieren | Mäßig (kontinuierlich) | 
| **Auswirkung auf die Quelldatenbank** | Minimale (Lesevorgänge) | Minimal (Versand wiederholen) | 
| **Am besten geeignet für** | Die meisten Migrationen, einfache Umstellung | Mission-critical, nahezu keine Ausfallzeiten erforderlich | 
| **Non-CDB Unterstützung** | Ja | Ja | 
| **Unterstützung für mehrere Mandanten** | Ja (gesamte CDB) | Ja (gesamte CDB) | 
| **Post-migration PDB-Status** | CDB geöffnet, PDBs MONTIERT | CDB geöffnet, PDBs MONTIERT | 
| **Erfordert RMAN** | Ja | Ja (für ein erstes Backup im Backup-basierten Ansatz) | 
| **Erfordert Data Guard** | Nein | Ja | 
| **Qualifikationsniveau erforderlich** | Intermediär | Advanced | 
| **Umstellungsprozess** | Leiten Sie Anwendungen zu EC2 um | Switchover-Befehl \+ Anwendungen umleiten | 

## Non-CDB Vergleich: Migration mit Multitenant-Migration
<a name="RDS-Custom-for-Oracle-end-of-support-non-cdb-va-multitenant"></a>

 

In der folgenden Tabelle sind die wichtigsten Unterschiede zwischen der Migration von Nicht-CDB-Datenbanken und Multitenant-Datenbanken zusammengefasst:


|  **Aspekt**  |  **Non-CDB Migration**  |  **Mehrmandanten-Migration (CDB mit PDBs)**  | 
| --- | --- | --- | 
| **Datenbanktyp** | Single-instance Nicht-CDB (z. B.) ORCL | CDB (Quelle:RDSCDB, Ziel:ORCL) mit CDB$ROOT \+ PDB$SEED \+ einer oder mehreren PDBs | 
| **Umfang der Migration** | Eine einzige Datenbank | Vollständige CDB (alle PDBs werden automatisch eingeschlossen) | 
| **Umfang der RMAN-Duplizierung** | Dupliziert eine einzelne Datenbank | Dupliziert die gesamte CDB (alle Container) | 
| **Geltungsbereich von Data Guard** | Schützt eine einzelne Datenbank | Schützt die gesamte CDB (alle PDBs werden automatisch eingeschlossen) | 
| **Parameterdatei** | Standard-Init-Parameter | Muss = enthalten enable\_pluggable\_database TRUE | 
| **Post-migration Datenbankstatus** | Die Datenbank wird im READ-WRITE-Modus geöffnet | CDB wird im READ WRITE Modus geöffnet; PDBs bleiben im Status MOUNTED | 
| **PDB wird geöffnet** | N/A | Muss alle PDBs manuell öffnen mit ALTER PLUGGABLE DATABASE ALL OPEN | 
| **PDB wird beim Start automatisch geöffnet** | N/A | Der PDB-Speicherstatus oder der Startauslöser müssen konfiguriert werden | 
| **Validierung** | Einzeldatenbankprüfungen | CDB und jede PDB müssen einzeln validiert werden | 
| **RDS-specific Aufräumen** |  users/objects Aus einer einzigen Datenbank löschen | Löscht gewöhnliche Benutzer aus CDB$ROOT (Kaskaden zu PDBs); behandelt C\#\#-Benutzer | 
| **TNS/Listener Konfiguration** | Ein einziger Dienst für die Datenbank | CDB-Dienst \+ einzelne PDB-Dienste, die dynamisch registriert wurden | 
| **Verbindungszeichenfolgen für Anwendungen** | Connect zu einer einzelnen Datenbank herstellen | Connect zu einzelnen PDB-Diensten her (nicht CDB) | 
| **Backup-Strategie** | Einzelne Datenbank Backup | Backup der gesamten CDB (einschließlich aller PDBs) oder einzelner PDBs | 
| **Ressourcenmanagement** | Database-level Ressourcenmanagement | CDB-level und PDB-level Ressourcenmanagement mit Resource Manager | 
| **Komplexität** | Geringere Komplexität | Höhere Komplexität aufgrund mehrerer Container und OMF-Pfade | 

## Bewährte Methoden und Empfehlungen
<a name="RDS-Custom-for-Oracle-end-of-support-best-practices"></a>

Dieser Abschnitt enthält umfassende bewährte Methoden für eine erfolgreiche Migration von RDS Custom for Oracle zu EC2.

### Pre-migration Planung
<a name="RDS-Custom-for-Oracle-end-of-support-best-practices-pre-migration"></a>

1. Führen Sie eine gründliche Bewertung durch:

   Bevor Sie mit der Migration beginnen, führen Sie eine umfassende Bewertung Ihrer Umgebung durch:
   + **Datenbankinventar**: Dokumentieren Sie alle Datenbanken, ihre Größen, Architekturen (ohne CDB oder Multitenant) und Abhängigkeiten
   + **Anwendungsabhängigkeiten**: Identifizieren Sie alle Anwendungen, die eine Verbindung zur Datenbank herstellen, und deren Verbindungsmethoden
   + **Leistungsbasis**: Erfassen Sie Leistungskennzahlen (CPU, Arbeitsspeicher I/O, Netzwerk) zum Vergleich nach der Migration
   + **Backup- und Wiederherstellungsanforderungen**: Dokument RPO (Recovery Point Objective) und RTO (Recovery Time Objective)
   + **Compliance-Anforderungen**: Identifizieren Sie alle regulatorischen oder Compliance-Anforderungen, die sich auf die Migration auswirken könnten

1. Wählen Sie den richtigen EC2-Instance-Typ:

   Wählen Sie einen EC2-Instance-Typ auf der Grundlage Ihrer Workload-Merkmale aus:    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/RDS-Custom-for-Oracle-end-of-support.html)

    **Richtlinien zur Instanzgröße:** 
   + Beginnen Sie mit derselben Instance-Klasse wie Ihre benutzerdefinierte RDS-Instance
   + Überwachen Sie die Ressourcennutzung während einer Testmigration
   + Erwägen Sie die Verwendung von AWS Compute Optimizer für Empfehlungen
   + Planen Sie einen Spielraum von 20 bis 30% für Wachstum und Spitzenlasten ein

1. Entwerfen Sie Ihre Speicherarchitektur:

   **EBS-Volumetypen:**    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/RDS-Custom-for-Oracle-end-of-support.html)

   **Empfehlungen für das Speicherlayout:**

   ```
   # Recommended layout for production databases
         /u01/app/oracle          # Oracle software (50-100 GB, gp3)
         /u01/app/oracle/oradata  # Data files (sized for database, gp3 or io2)
         /u01/app/oracle/arch     # Archive logs (separate volume, gp3)
         /u01/app/oracle/backup   # Backups (separate volume, gp3, can be detached post-migration)
   ```

    **Vorteile separater Volumen:** 
   + Unabhängige IOPS-Zuweisung
   + Einfacheres Kapazitätsmanagement
   + Vereinfachte Backup- und Snapshot-Strategien
   + Bessere Leistungsisolierung

1.  Erstellen Sie einen Rollback-Plan:

   Haben Sie immer eine Rollback-Strategie:
   + **Halten Sie die benutzerdefinierte RDS-Instanz während des Validierungszeitraums am Laufen** (1—2 Wochen empfohlen)
   + **Sorgen Sie für regelmäßige Backups** von Quell- und Zieldaten
   + **Dokumentieren Sie Rollback-Verfahren**, einschließlich Änderungen der Verbindungszeichenfolge
   + **Testen Sie den Rollback-Prozess** in einer Umgebung außerhalb der Produktionsumgebung
   + **Definieren Sie Rollback-Kriterien** (Leistungseinbußen, Dateninkonsistenz, Anwendungsfehler)

### Bewährte Methoden für die Durchführung der Migration
<a name="RDS-Custom-for-Oracle-end-of-support-migration-best-practices"></a>

1. **Zeitlicher Ablauf Ihrer Migration:**

   Wählen Sie das optimale Zeitfenster:
   + **Low-traffic Perioden**: Wochenende, Feiertage oder außerhalb der Hauptverkehrszeiten
   + **Wartungsfenster: Halten** Sie sich nach Möglichkeit an die geplanten Wartungsarbeiten
   + **Vermeiden Sie das end/quarter Monatsende: In** diesen Zeiträumen ist in der Regel ein hohes Transaktionsvolumen zu verzeichnen
   + **Berücksichtigen Sie Zeitzonen**: Wählen Sie für globale Anwendungen eine Zeit, die die Auswirkungen auf die einzelnen Regionen so gering wie möglich hält

1. **Kommunikationsplan:**

   Stellen Sie eine klare Kommunikation her:
   + **Benachrichtigung der Interessengruppen**: Informieren Sie alle Beteiligten mindestens 2 Wochen im Voraus
   + **Anwendungsteams: Stimmen** Sie sich mit den Anwendungsteams ab, um Aktualisierungen der Verbindungszeichenfolge vorzunehmen
   + **Statusaktualisierungen**: Stellen Sie während der Migration regelmäßige Updates bereit
   + **Eskalationspfad**: Definieren Sie klare Eskalationsverfahren für Probleme
   + **Post-migration Kommunikation**: Bestätigen Sie den erfolgreichen Abschluss und alle Folgemaßnahmen

1. **Prüfpunkte für die Validierung:**

   Implementieren Sie die Validierung in jeder Phase:

    **Pre-migration Validierung:** 

   ```
   -- Capture object counts
   SQL> SELECT object_type, COUNT(*) FROM dba_objects GROUP BY object_type ORDER BY object_type;
   
   -- Capture tablespace usage
   SQL> SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024/1024, 2) AS size_gb
   FROM dba_data_files GROUP BY tablespace_name;
   
   -- Capture user counts
   SQL> SELECT COUNT(*) FROM dba_users;
   
   -- For multitenant, capture PDB information
   SQL> SELECT con_id, name, open_mode FROM v$pdbs;
   ```

    **Post-migration Validierung:** 

   ```
   -- Verify object counts match
   SQL> SELECT object_type, COUNT(*) FROM dba_objects GROUP BY object_type ORDER BY object_type;
   
   -- Verify no invalid objects
   SQL> SELECT owner, object_type, object_name FROM dba_objects WHERE status = 'INVALID';
   
   -- Verify tablespace usage
   SQL> SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024/1024, 2) AS size_gb
   FROM dba_data_files GROUP BY tablespace_name;
   
   -- Verify database size matches
   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM dba_data_files;
   
   -- For multitenant, verify all PDBs are open
   SQL> SELECT con_id, name, open_mode FROM v$pdbs;
   ```

1. **Validierung der Leistung:**

   Vergleichen Sie die Leistungskennzahlen vor und nach der Migration:

   ```
   -- Capture AWR snapshots before migration (on RDS Custom)
   SQL> EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;
   
   -- After migration (on EC2), compare metrics
   SQL> SELECT snap_id, begin_interval_time, end_interval_time
   FROM dba_hist_snapshot
   ORDER BY snap_id DESC
   FETCH FIRST 10 ROWS ONLY;
   
   -- Generate AWR report for comparison
   SQL> @?/rdbms/admin/awrrpt.sql
   ```

   Wichtige Kennzahlen zum Vergleich:
   + Durchschnittliche aktive Sitzungen
   + DB-Zeit pro Transaktion
   + Physische Lesevorgänge pro Sekunde
   + Logische Lesevorgänge pro Sekunde
   + Redo-Größe pro Sekunde
   + Benutzeranrufe pro Sekunde
   + Analysezeit pro Ausführung

### Post-migration Optimierung
<a name="RDS-Custom-for-Oracle-end-of-support-best-practices-post-migration-optimization"></a>

1. Optimieren Sie nach der Migration die Datenbankleistung:

   1. **Optimierung der Datenbankleistung:**

       **Statistiken sammeln:** 

      ```
      -- Gather dictionary statistics
      SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
      
      -- Gather fixed object statistics
      SQL> EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
      
      -- Gather schema statistics
      SQL> EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SCHEMA_NAME', cascade=>TRUE);
      
      -- For multitenant, gather statistics for each PDB
      SQL> ALTER SESSION SET CONTAINER = PDB_NAME;
      SQL> EXEC DBMS_STATS.GATHER_DATABASE_STATS(cascade=>TRUE);
      ```

      **Speicherparameter optimieren:**

      ```
      -- Enable Automatic Memory Management (if not already enabled)
      SQL> ALTER SYSTEM SET MEMORY_TARGET = 24G SCOPE=SPFILE;
      SQL> ALTER SYSTEM SET MEMORY_MAX_TARGET = 28G SCOPE=SPFILE;
      SQL> SHUTDOWN IMMEDIATE;
      SQL> STARTUP;
      
      -- Or use Automatic Shared Memory Management
      SQL> ALTER SYSTEM SET SGA_TARGET = 16G SCOPE=SPFILE;
      SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 8G SCOPE=SPFILE;
      ```

      **Ergebnis-Cache konfigurieren:**

      ```
      -- Enable result cache for frequently accessed queries
      SQL> ALTER SYSTEM SET RESULT_CACHE_MAX_SIZE = 1G;
      SQL> ALTER SYSTEM SET RESULT_CACHE_MODE = MANUAL;
      ```

   1. Speicheroptimierung:

      **Komprimierung aktivieren:**

      ```
      -- For tables with infrequent updates
      ALTER TABLE large_table MOVE COMPRESS FOR OLTP;
      
      -- For archive/historical data
      ALTER TABLE archive_table MOVE COMPRESS FOR ARCHIVE HIGH;
      
      -- Rebuild indexes after compression
      ALTER INDEX index_name REBUILD ONLINE;
      ```

      **Partitionierung implementieren:**

      ```
      -- For large tables, consider partitioning
      -- Example: Range partitioning by date
      CREATE TABLE sales_partitioned (
          sale_id NUMBER,
          sale_date DATE,
          amount NUMBER
      )
      PARTITION BY RANGE (sale_date) (
          PARTITION sales_2024 VALUES LESS THAN (TO_DATE('2025-01-01', 'YYYY-MM-DD')),
          PARTITION sales_2025 VALUES LESS THAN (TO_DATE('2026-01-01', 'YYYY-MM-DD')),
          PARTITION sales_2026 VALUES LESS THAN (MAXVALUE)
      );
      ```

   1. Implementieren Sie Überwachung und Warnmeldungen:

      **CloudWatch benutzerdefinierte Metriken:**

      Erstellen Sie ein Skript zum Veröffentlichen von Oracle-Metriken in CloudWatch:

      ```
      #!/bin/bash
      # publish_oracle_metrics.sh
      
      INSTANCE_ID=$(ec2-metadata --instance-id | cut -d " " -f 2)
      REGION=$(ec2-metadata --availability-zone | cut -d " " -f 2 | sed 's/[a-z]$//')
      
      # Get tablespace usage
      TABLESPACE_USAGE=$(sqlplus -s / as sysdba << EOF
      SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF HEADING OFF ECHO OFF
      SELECT ROUND(MAX(percent_used), 2)
      FROM (
           SELECT tablespace_name,
                  ROUND((used_space/tablespace_size)*100, 2) AS percent_used
           FROM dba_tablespace_usage_metrics
      );
      EXIT;
      EOF
      )
      
      # Publish to CloudWatch
      aws cloudwatch put-metric-data \
        --region $REGION \
        --namespace "Oracle/Database" \
        --metric-name "TablespaceUsage" \
        --value $TABLESPACE_USAGE \
        --unit Percent \
        --dimensions InstanceId=$INSTANCE_ID,Database=ORCL
      # Add more metrics as needed (sessions, wait events, etc.)
      ```

      ** CloudWatch Alarme einrichten:**

      ```
      # Create alarm for high tablespace usage
      aws cloudwatch put-metric-alarm \
        --alarm-name oracle-high-tablespace-usage \
        --alarm-description "Alert when tablespace usage exceeds 85%" \
        --metric-name TablespaceUsage \
        --namespace Oracle/Database \
        --statistic Maximum \
        --period 300 \
        --evaluation-periods 2 \
        --threshold 85 \
        --comparison-operator GreaterThanThreshold \
        --alarm-actions arn:aws:sns:region:account-id:topic-name
      ```

   1. Verhärtung der Sicherheit:

      **Datenbanksicherheit:**

      ```
      -- Enforce password complexity
      ALTER PROFILE DEFAULT LIMIT
          PASSWORD_LIFE_TIME 90
          PASSWORD_GRACE_TIME 7
          PASSWORD_REUSE_TIME 365
          PASSWORD_REUSE_MAX 5
          FAILED_LOGIN_ATTEMPTS 5
          PASSWORD_LOCK_TIME 1;
      
      -- Enable audit
      ALTER SYSTEM SET AUDIT_TRAIL = DB, EXTENDED SCOPE=SPFILE;
      SHUTDOWN IMMEDIATE;
      STARTUP;
      
      -- Audit critical operations
      AUDIT ALL ON SYS.AUD$ BY ACCESS;
      AUDIT CREATE USER BY ACCESS;
      AUDIT DROP USER BY ACCESS;
      AUDIT ALTER USER BY ACCESS;
      AUDIT CREATE SESSION BY ACCESS WHENEVER NOT SUCCESSFUL;
      ```

      **Netzwerksicherheit:**

      ```
      # Restrict SSH access
      sudo vi /etc/ssh/sshd_config
      # Set: PermitRootLogin no
      # Set: PasswordAuthentication no
      
      # Configure firewall
      sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.0/8" port port="1521" protocol="tcp" accept'
      sudo firewall-cmd --reload
      
      # Enable Oracle Native Network Encryption
      # Edit sqlnet.ora
      SQLNET.ENCRYPTION_SERVER = REQUIRED
      SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128)
      SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
      SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA384, SHA512)
      ```

1. Backup- und Wiederherstellungsstrategie:

   **Implementieren Sie eine umfassende Backup-Strategie:**

   ```
   #!/bin/bash
   # rman_backup.sh - Daily incremental backup script
   
   export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
   export ORACLE_SID=ORCL
   export PATH=$ORACLE_HOME/bin:$PATH
   
   # Backup to local disk
   rman target / << EOF
   RUN {
       ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT '/u01/app/oracle/backup/inc_%U';
       BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;
       DELETE NOPROMPT OBSOLETE;
       CROSSCHECK BACKUP;
       DELETE NOPROMPT EXPIRED BACKUP;
   }
   EXIT;
   EOF
   
   # Copy backups to S3
   aws s3 sync /u01/app/oracle/backup/ s3://my-oracle-backups/$(date +%Y%m%d)/ \
       --storage-class STANDARD_IA \
       --exclude "*" \
       --include "inc_*" \
       --include "arch_*"
   
   # Clean up local backups older than 7 days
   find /u01/app/oracle/backup/ -name "inc_*" -mtime +7 -delete
   find /u01/app/oracle/backup/ -name "arch_*" -mtime +7 -delete
   ```

   **Planen Sie Backups mit Cron:**

   ```
   # Edit crontab
   crontab -e
   
   # Add backup schedule
   # Full backup on Sunday at 2 AM
   0 2 * * 0 /home/oracle/scripts/rman_full_backup.sh >> /home/oracle/logs/backup_full.log 2>&1
   
   # Incremental backup Monday-Saturday at 2 AM
   0 2 * * 1-6 /home/oracle/scripts/rman_incremental_backup.sh >> /home/oracle/logs/backup_inc.log 2>&1
   
   # Archive log backup every 4 hours
   0 */4 * * * /home/oracle/scripts/rman_archivelog_backup.sh >> /home/oracle/logs/backup_arch.log 2>&1
   ```

### Kostenoptimierung
<a name="RDS-Custom-for-Oracle-end-of-support-cost-optimization"></a>

 **1. Right-sizing**: 

Überwachen und optimieren Sie die Kosten nach der Migration:
+ **Verwenden Sie den AWS Cost Explorer**, um die EC2- und EBS-Kosten zu analysieren
+ ** AWS Compute Optimizer für Empfehlungen zu Instanztypen aktivieren**
+ **Überprüfen Sie die CloudWatch Kennzahlen**, um nicht ausgelastete Ressourcen zu identifizieren
+ **Ziehen Sie Reserved Instances** oder Savings Plans für vorhersehbare Workloads in Betracht

 **2. Speicheroptimierung:** 
+ **Implementieren Sie Lebenszyklusrichtlinien** für S3-Backups (wechseln Sie nach 30 Tagen zu Glacier)
+ **Löschen Sie regelmäßig ungenutzte EBS-Snapshots**
+ **Verwenden Sie gp3 anstelle von gp2** für Kosteneinsparungen bei gleicher Leistung
+ **Trennen und löschen Sie die Backup-Volumes** nach Abschluss der Migration

 **3. Automatisierung:** 
+ **Automatisierung start/stop** von Datenbanken außerhalb der Geschäftszeiten
+ **Verwenden Sie AWS Systems Manager** für das Patch-Management
+ **Implementieren Sie die auto-scaling** für Read Replicas, wenn Sie Data Guard verwenden

## Schlussfolgerung
<a name="RDS-Custom-for-Oracle-end-of-support-conclusion"></a>

Diese präskriptiven Leitlinien enthielten detaillierte Migrationsstrategien für die Migration Ihrer Oracle-Datenbanken von Amazon RDS Custom for Oracle zu selbstverwalteten Oracle-Datenbanken auf Amazon EC2. Da der Dienst RDS Custom for Oracle mit Wirkung zum 31. März 2027 nicht mehr unterstützt wird, ist es wichtig, dass Sie Ihre Migration rechtzeitig planen und durchführen.

 **Die wichtigsten Erkenntnisse** 

 **Optionen für die Migration:** 
+ **Aktive RMAN-Duplikation**: Für die meisten Migrationen am besten geeignet, hält die Quelldatenbank während der Duplizierung online und erfordert nur ein kurzes Umstellungsfenster für die Anwendungsumleitung
+ **Oracle Data Guard**: Am besten für unternehmenskritische Workloads geeignet, die nahezu keine Ausfallzeiten erfordern. Es bietet kontinuierliche Synchronisation und integrierte Switchover-Funktionen

 **Architekturunterstützung:** 
+ Beide Migrationsoptionen unterstützen Nicht-CDB-Architekturen (herkömmliche Einzelinstanz) und Mehrmandantenarchitekturen (CDB mit PDBs)
+ Bei Mehrmandantenfähigkeit verarbeiten beide Methoden automatisch die gesamte CDB einschließlich aller PDBs in einem einzigen Vorgang
+ PDBs müssen nach der Migration manuell geöffnet und automatisch geöffnet werden

 **Kritische Erfolgsfaktoren:** 
+ Richtige Netzwerkkonfiguration und Konnektivität zwischen Quelle und Ziel
+ Exakte Versionskompatibilität (Hauptversion, Nebenversion, Release-Update und einmalige Patches)
+ Ausreichende Netzwerkbandbreite für Datenübertragung (RMAN) oder Redo-Shipping (Data Guard)
+ Wir wissen, dass die Quelle durch aktive RMAN-Duplizierung online bleibt — es ist nur eine kurze Umstellung erforderlich
+ Gründliche Tests und Validierung vor der Außerbetriebnahme der Quelle
+ Umfassende Aufgaben nach der Migration, einschließlich Sicherung, Überwachung und Sicherheitskonfiguration

 **Die nächsten Schritte:** 

1. Beurteilen Sie Ihre Datenbankarchitektur (ohne CDB oder mandantenfähig)

1. Wählen Sie die passende Migrationsoption auf der Grundlage Ihrer Anforderungen an Ausfallzeit, Toleranz und Komplexität

1. Schließen Sie alle erforderlichen Schritte ab, einschließlich der Einrichtung der EC2-Instanz und der Netzwerkkonfiguration

1. Folgen Sie den detaillierten Migrationsschritten für die von Ihnen gewählte Option

1. Führen Sie gründliche Validierungen und Tests durch

1. Erledigen Sie die Aufgaben nach der Migration, um die Produktionsbereitschaft sicherzustellen

1. Nehmen Sie die RDS Custom-Instance nach erfolgreicher Validierung außer Betrieb

 **Weitere Ressourcen** 
+ [Amazon RDS Custom for Oracle — Benutzerhandbuch](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom.html)
+ [Dokumentation zur Oracle-Datenbank](https://docs.oracle.com/en/database/)
+ [Oracle RMAN-Dokumentation](https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/)
+ [Oracle Data Guard-Dokumentation](https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/)
+ [AWS Database Migration Service](https://aws.amazon.com/dms/)
+ [AWS Präskriptive Leitlinien](https://aws.amazon.com/prescriptive-guidance/)

 **Support** 

Wenn Sie Unterstützung bei Ihrer Migration benötigen:
+ Wenden Sie sich über die AWS Management Console an den AWS Support
+ Wenden Sie sich bei datenbankspezifischen Fragen an den Oracle-Support

## **Informationen zum Dokument**
<a name="RDS-Custom-for-Oracle-end-of-support-document-information"></a>

**Letzte Aktualisierung:** März 2026

**Mitwirkende:**
+ Sharath Chandra Kampili, Lösungsarchitektin für Datenbankspezialisten, Amazon Web Services
+ Ibrahim Emara, Datenbankspezialist, Lösungsarchitekt, Amazon Web Services
+ Vetrivel Subramani, Datenbankspezialist, Lösungsarchitekt, Amazon Web Services