RDS Custom for Oracle 终止支持

1. 启动和配置 EC2 实例

   启动 EC2 实例时应考虑以下注意事项：

   • 实例类型：选择可满足工作负载的资源要求的 EC2 实例类型。使用与 RDS Custom 实例相同的实例类是一个不错的起点。考虑内存、CPU 和网络带宽要求。

   • 操作系统：Oracle Linux 或 Red Hat Enterprise Linux（与您的 RDS Custom 操作系统版本匹配或兼容）

   • Oracle 软件：安装 Oracle Database 软件（与 RDS Custom 相同的主要版本、次要版本、版本更新，最好是相同的一次性补丁）。确保 Oracle 软件安装在 /u01/app/oracle/ 中或您的首选位置。

   • 存储：将 Amazon EBS 卷配置为适当的大小和 IOPS，以满足您的工作负载要求。考虑使用 gp3 卷来获得经济高效的性能，或者使用 io2 Block Express 来处理高性能工作负载。

2. 配置存储架构

   1. 文件系统存储（建议用于大多数场景）

      • 使用标准文件系统目录来处理 Oracle 数据文件

      • 管理更简单，适用于大多数工作负载

      • 本指南使用文件系统存储示例

   2. Oracle Automatic Storage Management（ASM）

      • 如果您的工作负载需要 ASM，请在 EC2 实例上安装和配置独立的 ASM

      • 相应地调整 init 文件中的所有路径参数以使用 ASM 磁盘组（例如 +DATA、+FRA）

      • 用于 ASM 的迁移过程类似，只是调整了路径

3. 设置文件传输机制

   创建在 RDS Custom 实例和 EC2 实例之间传输文件的机制。您有多种选择：

   1. 选项 A：Amazon S3（建议用于大多数场景）

      • 创建 Amazon S3 存储桶或使用现有存储桶

      • 在这两个实例上安装和配置 AWS CLI

      • 有关说明，请参阅开始使用 AWS CLI。

   2. 选项 B：直接 SCP/SFTP

      • 如果 SSH 端口在实例之间处于打开状态，则可以直接传输文件

      • 适用于诸如参数文件和密码文件等小文件

   3. 选项 C：Amazon EFS

      • 如果您已经在这两个实例上挂载了 Amazon EFS，则可以将其用作共享的文件系统

      • 适用于采用现有 EFS 基础设施的环境

      本指南使用 Amazon S3 作为示例，但您可以根据所选方法调整命令。

4. 配置网络连接

   确保 RDS Custom 和 EC2 实例之间的网络连接：

   • 相同的 VPC：安全组必须在 Oracle 侦听器端口（默认 1521 或您的自定义端口）上支持双向流量

   • 不同的 VPC（同一个账户）：设置 VPC 对等互连并配置路由表和安全组

   • 不同的账户：设置跨账户 VPC 对等连接或使用 AWS Transit Gateway

   • 验证连接：使用 ping 和 telnet 来测试数据库端口上的连接

5. 在 EC2 上创建目录结构

   目录结构取决于数据库架构：

   例对于非 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

   例对于多租户（带有 PDB 的 CDB）

   # 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

   注意

   RDS Custom for Oracle 使用 Oracle 托管式文件（OMF）来管理 PDB 数据文件，并采用基于 GUID 的子目录（例如 /rdsdbdata/db/pdb/RDSCDB_A/{GUID}/datafile/）。迁移过程将自动在目标上创建必要的子目录结构。您只需创建父目录即可。

   存储策略：考虑为 /u01/app/oracle/backup 使用单独的 EBS 卷，以便在迁移完成后轻松将其分离和移除，从而节省存储成本。

6. 验证源数据库配置

1. 以 rdsdb 用户身份登录 RDS Custom 数据库主机并设置环境：

   例

   # 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. 连接到数据库并检查架构：

   例

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

   例对于非 CDB，预期输出

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

   例对于多租户（CDB），预期输出：

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

3. 如果您有多租户 CDB，请列出所有 PDB 及其状态：

   例

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

   预期输出（具有 1 个名为 ORCLDB 的 PDB 的示例）：

   例

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

4. 检查数据库的总大小：

   例对于非 CDB：

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

   例对于多租户：

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

典型时间表

1. 复制阶段（源保持在线）：30 分钟到几个小时，具体取决于数据库大小

2. 验证阶段（源保持在线）：根据需要，数小时到数天

3. 割接阶段（短暂的停机时间）：将应用程序重定向到 EC2 需要几分钟

RDS Custom 数据库实例（源）步骤：

1. 暂停 Amazon RDS Custom 自动化

2. 验证数据库架构（非 CDB 或带有 PDB 的 CDB）

3. 从源数据库创建密码文件和参数文件

4. 将密码文件和参数文件复制到目标 EC2 实例

5. 验证源数据库是否在归档日志模式下运行

6. 在 RDS Custom 数据库服务器上配置 tnsnames.ora

EC2 数据库实例（目标）步骤：

1. 编辑 EC2 的参数文件（架构特定）

2. 在 EC2 上配置 tnsnames.ora

3. 配置 EC2 实例的环境

4. 在 EC2 上配置 Oracle 侦听器

5. 在 EC2 上以 NOMOUNT 状态启动数据库

RMAN 复制步骤：

1. 执行 RMAN 主动复制

2. 打开数据库（对于多租户，打开 PDB）

3. 配置 PDB 自动打开（仅限多租户）

4. 移除 RDS Custom 特定的用户和对象

5. 创建 SPFILE 并配置自动启动

6. 在源上恢复 Amazon RDS Custom 自动化（如果保持活动状态）

1. 更新数据库名称：对于多租户，将出现的所有 RDSCDB 更改为 ORCL

2. 将 RDS Custom 路径转换为 EC2 路径：将 /rdsdbdata/ 替换为 /u01/app/oracle/

3. 移除 RDS Custom 特定的参数

   • dg_broker_config_file1 和 dg_broker_config_file2（如果存在 - 表示已存在副本）

   • standby_file_management（如果存在）

   • spfile（稍后我们将创建一个新的 SPFILE）

   • 任何指向备用目标的 log_archive_dest 参数（仅保留 log_archive_dest_1 用于本地归档）

4. 添加文件名转换参数（见下文）

5. 根据您的 EC2 实例大小调整内存参数（可选，但建议采用）

RMAN 主动复制过程包括几个阶段：

1. 连接到源数据库和目标数据库

2. 在目标上从内存中创建 SPFILE

3. 将控制文件还原到目标

4. 挂载目标数据库

5. 通过网络将所有数据文件从源复制到目标（源保持在线）

6. 恢复目标数据库

7. 使用 RESETLOGS 打开目标数据库

1. 监控 RMAN 输出：

   RMAN 会话将显示详细的进度信息，包括：

   • 通道分配

   • 数据文件复制进度

   • 估计的完成时间

   • 已处理的字节数

   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

   例输出示例：

   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. 监控长时间运行的操作：

   例在目标 EC2 实例上单独的 SQL*Plus 会话中：

   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;

   此查询显示：

   • opname：操作名称（例如，“RMAN: full datafile restore”）

   • sofar：到目前为止处理的块数

   • totalwork：要处理的块总数

   • pct_complete：完成百分比

   • time_remaining：估计剩余秒数

   • elapsed_seconds：到目前为止过去的时间

3. 监控 RMAN 通道：

   例

   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. 查看警报日志：

   例在目标 EC2 实例上，监控警报日志中是否存在任何错误或警告：

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

   RMAN 复制过程中的常见问题：

   • 网络超时

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

     解决方案：增加这两个实例上的 sqlnet.ora 网络超时值：

     SQLNET.RECV_TIMEOUT=600
     SQLNET.SEND_TIMEOUT=600

   • 目标上的空间不足

     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

     解决方案：检查可用空间并添加更多 EBS 卷容量：

     df -h /u01/app/oracle/oradata

   • 参数文件错误

     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

     解决方案：验证参数文件中的所有目录都存在且具有正确的权限。

   • 密码文件不匹配

     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

     解决方案：确保目标上的密码文件与源匹配且名称正确 (orapwORCL)。

RDS Custom 数据库实例（主实例）步骤：

1. 暂停 Amazon RDS Custom 自动化

2. 验证数据库架构（非 CDB 或带有 PDB 的 CDB）

3. 确认主数据库正在归档日志模式下运行并且已启用 FORCE_LOGGING

4. 创建密码文件

5. 对主数据库执行 RMAN 在线备份（或使用主动复制）

6. 从源数据库创建参数文件

7. 将备份集、参数文件和密码文件复制到目标 EC2 实例

EC2 数据库实例（备用实例）步骤：

1. 将源中的所有文件复制到 EC2 实例

2. 将密码文件复制到 EC2 实例

3. 编辑 EC2 的参数文件（架构特定）

4. 从参数文件创建服务器参数文件

5. 还原备用控制文件和数据库

Data Guard 配置步骤：

1. 在两个实例上配置 Oracle 侦听器

2. 在两个实例上配置 tnsnames.ora

3. 在两个实例上启动 Oracle Data Guard 代理（可选，但建议这样做）

4. 启用 Oracle Data Guard 配置

5. 在 EC2 备用实例上配置 fal_server 和 fal_client

6. 在两个实例上配置备用重做日志文件

7. 恢复备用实例

8. 执行手动切换

9. 打开数据库（对于多租户，打开 PDB）

10. 配置 PDB 自动打开（仅限多租户）

11. 移除 RDS Custom 特定的用户和对象

12. 创建 SPFILE 并配置自动启动

1. 更新数据库名称：对于多租户，将出现的所有 RDSCDB 更改为 ORCL

2. 更改 db_unique_name：从 ORCL_A（或 RDSCDB_A）更改为 ORCL_B

3. 将 RDS Custom 路径转换为 EC2 路径：将 /rdsdbdata/ 替换为 /u01/app/oracle/

4. 移除 RDS Custom 特定的参数

   • dg_broker_config_file1 和 dg_broker_config_file2（如果存在）

   • standby_file_management（如果存在）

   • spfile（稍后我们将创建一个新的 SPFILE）

   • 任何指向备用目标的 log_archive_dest 参数

5. 根据您的 EC2 实例大小调整内存参数（可选，但建议采用）

1. 监控 Data Guard 统计数据：

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

   要监控的关键指标：

   • 传输滞后：在主实例上生成重做与在备用实例上收到重做的时间之间的时间差

   • 应用滞后：生成重做与在备用实例上应用重做的时间之间的时间差

   • 应用速率：应用重做操作的速率（MB/秒）

   • 收到的重做：备用实例接收的重做总数

   • 应用的重做：备用实例应用的重做总数

2. 监控归档日志传送：

   在主实例上（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';

   在备用实例上（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. 监控托管恢复过程：

   -- 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. 监控多租户的重做应用速率：

   对于多租户数据库，监控每个 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. 监控备用重做日志：

   -- 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. 估计同步完成：

   根据应用速率计算剩余时间：

   -- 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. 检查时区版本：

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

2. 一种解决方法是将时区文件环境变量设置为与 $ORACLE_HOME 的可用变量相匹配：

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

   调整数字，使其与安装中可用的版本相匹配。

3. 重试删除：

   sqlplus / as sysdba
   SQL> DROP USER RDSADMIN CASCADE;

1. 同时检查源和目标上确切的 RU 版本：

   -- 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. 验证 $ORACLE_HOME 补丁级别：

   # On both instances
   $ORACLE_HOME/OPatch/opatch lsinventory

3. 如果版本不匹配，请在迁移之前根据需要应用或回滚补丁来使版本一致。

4. 如果您必须继续使用不匹配的 RU，请在迁移后运行 datapatch：

   cd $ORACLE_HOME/OPatch
   ./datapatch -verbose

5. 检查是否存在无效对象，然后重新编译：

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

1. 验证安全组双向支持端口

2. 在 EC2 上检查 iptables：

   sudo iptables -L INPUT -n -v

3. 如果需要，则添加规则：

   # 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. 连接测试：

   telnet <EC2_instance_IP> 1521
   tnsping DB_SOURCE
   tnsping DB_TARGET

1. 检查缺少哪些数据文件：

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

2. 如果文件放在错误的目录中，请在控制文件中对它们重命名：

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

3. 为防止出现这种情况，在配置参数文件之前，请务必使用 SELECT con_id, name FROM v$datafile ORDER BY con_id; 验证源数据文件路径。

1. 强制服务注册：

   SQL> ALTER SYSTEM REGISTER;

2. 如果服务仍未显示，请检查以下 local_listener 参数：

   SQL> SHOW PARAMETER local_listener;

   确保它指向正确的侦听器地址。如果需要，请对其进行更新：

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

3. 使用以下命令进行验证：

   lsnrctl services

1. 验证备用实例是否处于 MOUNT 模式：

   SQL> SELECT status FROM v$instance;

2. 检查是否在备用实例上正确设置了 fal_server 和 fal_client：

   SQL> SHOW PARAMETER fal_server
   SQL> SHOW PARAMETER fal_client

3. 验证网络连接：

   tnsping ORCL_A # or RDSCDB_A for multitenant

4. 检查主实例上的 log_archive_dest_2 参数指向备用实例（如果在没有代理的情况下手动配置）。

1. 查看应用速率：

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

2. 考虑增加重做应用的并行度（需要 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;

3. 验证备用实例上没有资源约束（CPU、I/O）。

1. 交叉检查并清理过时的归档日志条目：

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

2. 仅重新运行归档日志备份：

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

1. 最终备份：出于归档目的，对 RDS Custom 实例进行最终备份

   # 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. 记录迁移：使用新的 EC2 配置更新运行手册和文档

3. 删除 RDS Custom 实例：使用 AWS 控制台或 CLI 来删除实例

   # 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. 清理资源：如果不再需要，则移除关联的快照、参数组和选项组

5. 更新文档：确保所有操作文档都反映基于 EC2 的新架构

1. 进行全面评测：

   在开始迁移之前，请对您的环境进行全面评测：

   • 数据库清单：记录所有数据库、其大小、架构（非 CDB 与多租户）和依赖关系

   • 应用程序依赖关系：确定所有连接到数据库的应用程序及其连接方法

   • 性能基准：捕获性能指标（CPU、内存、I/O、网络），以便在迁移后进行比较

   • 备份和恢复要求：记录 RPO（恢复点目标）和 RTO（恢复时间目标）

   • 合规性要求：确定可能影响迁移的任何监管或合规要求

2. 选择合适的 EC2 实例类型：

   根据您的工作负载特征选择 EC2 实例类型：

   工作负载类型	建议的实例系列	主要特征
   通用型 OLTP	M6i、M6a、M7i	平衡计算、内存和网络
   内存密集型	R6i、R6a、R7i、X2idn	较高的内存与 CPU 比率
   计算密集型	C6i、C6a、C7i	较高的 CPU 性能
   I/O 密集型	I4i、Im4gn	较高的本地 NVMe SSD 存储
   混合工作负载	M5、M5a、M5n	成本效益与性能均衡

   实例大小指南：

   • 以与 RDS Custom 实例相同的实例类开始

   • 监控测试迁移期间的资源利用率

   • 考虑使用 AWS Compute Optimizer 获取建议

   • 规划 20-30% 的余量以应对增长和峰值负载

3. 设计您的存储架构：

   EBS 卷类型：

   卷类型	使用场景	性能：	成本。
   gp3	一般用途，大多数工作负载	最高可达 16000 IOPS、1000 MB/s	低
   io2 Block Express	任务关键型、高性能	最高可达 256000 IOPS、4000 MB/s	高
   Io1	高性能数据库	最高可达 64000 IOPS、1000 MB/s	中高
   gp2	传统通用型	最高可达 16000 IOPS	低

   存储布局建议：

   # 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)

   单独卷的优势：

   • 独立的 IOPS 分配

   • 更轻松的容量管理

   • 简化的备份和快照策略

   • 更好的性能隔离

4. 制定回滚计划：

   始终具有回滚策略：

   • 在验证期（建议 1-2 周）内保持 RDS Custom 实例运行

   • 保持定期备份源和目标

   • 记录回滚过程，包括连接字符串更改

   • 在非生产环境中测试回滚过程

   • 定义回滚标准（性能降级、数据不一致、应用程序错误）

1. 安排迁移时间：

   选择最佳时段：

   • 低流量时段：周末、节假日或非高峰时段

   • 维护时段：如果可能，请与定期维护保持一致

   • 避免月末/季度末：这些时段的事务量通常很高

   • 考虑时区：对于全球应用程序，请选择能够最大限度地减少跨区域影响的时间

2. 沟通计划：

   建立清晰的沟通：

   • 利益相关者通知：至少提前 2 周通知所有利益相关者

   • 应用程序团队：与应用程序团队协调更新连接字符串

   • 状态更新：在迁移期间提供定期更新

   • 上报路径：为问题定义明确的上报程序

   • 迁移后沟通：确认成功完成并采取任何后续行动

3. 验证检查点：

   在每个阶段实施验证：

   迁移前验证：

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

   迁移后验证：

   -- 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. 性能验证：

   比较迁移前后的性能指标：

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

   要比较的关键指标：

   • 平均活动会话数

   • 每个事务的数据库时间

   • 每秒物理读取次数

   • 每秒逻辑读取次数

   • 每秒重做大小

   • 每秒用户调用数

   • 每次执行的解析时间

1. 迁移后，优化数据库性能：

   1. 数据库性能调优：

      收集统计数据：

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

      优化内存参数：

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

      配置结果缓存：

      -- 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. 存储优化：

      启用压缩：

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

      实施分区：

      -- 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. 实施监控和警报：

      CloudWatch 自定义指标：

      创建脚本以将 Oracle 指标发布到 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 警报。

      # 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. 安全固化：

      数据库安全

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

      网络安全性

      # 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. 备份和恢复策略：

   实施全面的备份策略：

   #!/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

   使用 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. 评测您的数据库架构（非 CDB 或多租户）

2. 根据您的停机时间容限和复杂度要求选择适当的迁移选项

3. 完成所有先决条件步骤，包括 EC2 实例设置和网络配置

4. 按照所选选项的详细迁移步骤进行操作

5. 执行彻底的验证和测试

6. 完成迁移后任务以确保生产准备就绪

7. 成功验证后停用 RDS Custom 实例