Ende des Supports für RDS Custom für Oracle

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.

2. 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

   2. 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

3. 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.

   2. 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

   3. 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.

4. 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

5. Erstellen Sie eine Verzeichnisstruktur auf EC2

   Die Verzeichnisstruktur hängt von Ihrer Datenbankarchitektur ab:

   Beispiel 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

   Beispiel 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.

6. Überprüfen Sie die Konfiguration der Quelldatenbank

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

   Beispiel

   # 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

2. Connect zur Datenbank her und überprüfen Sie die Architektur:

   Beispiel

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

   Beispiel Für Non-CDB, erwartete Ausgabe

   NAME CDB OPEN_MODE                 LOG_MODE
   --------- --- -------------------- ------------
   ORCL NO  READ  WRITE               ARCHIVELOG

   Beispiel Für Multitenant (CDB) erwartete Ausgabe:

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

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

   Beispiel

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

   Erwartete Ausgabe (Beispiel mit einer PDB namens ORCLDB):

   Beispiel

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

4. Überprüfen Sie die Gesamtgröße der Datenbank:

   Beispiel Für Non-CDB:

   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM dba_data_files;

   Beispiel 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;

Typischer Zeitplan

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

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

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

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

1. Benutzerdefinierte Amazon RDS-Automatisierung pausieren

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

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

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

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

6. 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)

2. Konfigurieren Sie tnsnames.ora auf EC2

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

4. Konfigurieren Sie Oracle Listener auf EC2

5. Starten Sie die Datenbank auf EC2 im Status NOMOUNT

Schritte zur RMAN-Duplizierung:

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

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

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

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

5. Erstellen Sie SPFILE und konfigurieren Sie den automatischen Start

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

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

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

3. Custom-specific Entfernen Sie RDS-Parameter

   • dg_broker_config_file1und 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)

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

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

Der aktive RMAN-Duplizierungsprozess umfasst mehrere Phasen:

1. Verbindung zu Quell- und Zieldatenbanken herstellen

2. Eine SPFILE aus dem Speicher auf dem Ziel erstellen

3. Die Steuerdatei auf dem Ziel wiederherstellen

4. Mounten der Zieldatenbank

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

6. Die Zieldatenbank wird wiederhergestellt

7. Öffnen der Zieldatenbank mit RESETLOGS

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

   Beispiel 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

2. Überwachen Sie lang andauernde Operationen:

   Beispiel 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

3. RMAN-Kanäle überwachen:

   Beispiel

   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;

4. Überprüfen Sie das Warnungsprotokoll:

   BeispielÜ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).

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

1. Benutzerdefinierte Amazon RDS-Automatisierung pausieren

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

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

4. Erstellen Sie eine Passwortdatei

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

6. Erstellen Sie eine Parameterdatei aus der Quelldatenbank

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

2. Kopieren Sie die Passwortdatei auf die EC2-Instance

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

4. Erstellen Sie die Serverparameterdatei aus der Parameterdatei

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

Schritte zur Konfiguration von Data Guard:

1. Konfigurieren Sie Oracle-Listener auf beiden Instanzen

2. Konfigurieren Sie tnsnames.ora auf beiden Instanzen

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

4. Aktivieren Sie die Oracle Data Guard-Konfiguration

5. Konfigurieren Sie fal_server und fal_client auf der EC2-Standby-Instanz

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

7. Stellen Sie die Standby-Instanz wieder her

8. Führen Sie den manuellen Switchover durch

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

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

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

12. Erstellen Sie SPFILE und konfigurieren Sie den automatischen Start

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

2. Ändern Sie db_unique_name: Von (oder) zu ORCL_A RDSCDB_A ORCL_B

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

4. Custom-specific RDS-Parameter entfernen

   • dg_broker_config_file1und 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

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

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

2. 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;

3. Ü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;

4. Ü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;

5. 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';

6. 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;

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%';

2. 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.

3. Versuchen Sie es erneut mit dem Drop:

   sqlplus / as sysdba
   SQL> DROP USER RDSADMIN CASCADE;

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;

2. Überprüfen Sie das $ORACLE_HOME-Patch-Level:

   # On both instances
   $ORACLE_HOME/OPatch/opatch lsinventory

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

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

   cd $ORACLE_HOME/OPatch
   ./datapatch -verbose

5. 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;

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

2. Überprüfen Sie iptables auf EC2:

   sudo iptables -L INPUT -n -v

3. 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

4. Konnektivität testen:

   telnet <EC2_instance_IP> 1521
   tnsping DB_SOURCE
   tnsping DB_TARGET

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

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

2. 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';

3. 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.

1. Registrierung des Dienstes erzwingen:

   SQL> ALTER SYSTEM REGISTER;

2. 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;

3. Verifizieren Sie mit:

   lsnrctl services

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

   SQL> SELECT status FROM v$instance;

2. 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

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

   tnsping ORCL_A # or RDSCDB_A for multitenant

4. Überprüfen Sie den Parameter log_archive_dest_2 an den primären Bereitschaftspunkten (falls manuell ohne Broker konfiguriert).

1. Überprüfen Sie die Anwendungsrate:

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

2. 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;

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

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

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

2. 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;
   }

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

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

3. 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

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

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

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

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

   Wählen Sie einen EC2-Instance-Typ auf der Grundlage Ihrer Workload-Merkmale aus:

   Workload-Typ	Empfohlene Instance-Familie	Wichtigste Merkmale
   OLTP für allgemeine Zwecke	M6i, M6a, M7i	Ausgewogenes Verhältnis von Rechenleistung, Arbeitsspeicher und Netzwerk
   Memory-intensive	R6i, R6a, R7i, x2IDN	Hohes Verhältnis von Speicher zu CPU
   Compute-intensive	C6i, C6a, C7i	Hohe CPU-Leistung
   I/O-intensive	i4i, iM4GN	Hoher lokaler NVMe SSD-Speicher
   Gemischte Workloads	M5, M5a, M5n	Cost-effective ausgewogene Leistung

   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

3. Entwerfen Sie Ihre Speicherarchitektur:

   EBS-Volumetypen:

   Volume-Typ	Anwendungsfall	Leistung	Kosten
   gp3	Universell einsetzbar, die meisten Workloads	Bis zu 16.000 IOPS, 1.000 MB/s	Niedrig
   io2 Block Express	Mission-critical, leistungsstark	Bis zu 256.000 IOPS, 4.000 MB/s	Hoch
   Io1	High-performance Datenbanken	Bis zu 64.000 IOPS, 1.000 MB/s	Medium-High
   gp2	Ältere Versionen für allgemeine Zwecke	Bis zu 16.000 IOPS	Niedrig

   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

4. 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)

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

2. 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

3. 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;

4. 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

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;

   2. 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)
      );

   3. 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

   4. 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

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

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

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

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

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

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

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