RDS Custom for Oracle 終止支援

1. 啟動和設定 EC2 執行個體

   啟動具有下列考量的 EC2 執行個體：

   • 執行個體類型：選擇符合工作負載資源需求的 EC2 執行個體類型。使用與 RDS Custom 執行個體相同的執行個體類別是很好的起點。考慮記憶體、CPU 和網路頻寬需求。

   • 作業系統：Oracle Linux 或 Red Hat Enterprise Linux （與您的 RDS Custom OS 版本相符或相容）

   • Oracle 軟體：安裝 Oracle Database 軟體 （主要版本、次要版本、版本更新，以及理想情況下與 RDS Custom 相同的一次性修補程式）。確保 Oracle 軟體安裝在 /u01/app/oracle/ 或您偏好的位置。

   • 儲存：使用適當的大小和 IOPS 設定 Amazon EBS 磁碟區，以符合您的工作負載需求。考慮將 gp3 磁碟區用於經濟實惠的效能，或將 io2 Block Express 用於高效能工作負載。

2. 設定儲存架構

   1. 檔案系統儲存 （建議大多數案例使用）

      • 使用 Oracle 資料檔案的標準檔案系統目錄

      • 更輕鬆地管理和適用於大多數工作負載

      • 本指南使用檔案系統儲存範例

   2. Oracle 自動儲存管理 (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，或您的自訂連接埠）

   • 不同的 VPCs（相同帳戶）：設定 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

   範例對於多租戶 (CDB 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

   注意

   RDS Custom for Oracle 使用 Oracle Managed Files (OMF) 搭配 GUID 型子目錄 （例如 /rdsdbdata/db/pdb/RDSCDB_A/{GUID}/datafile/) 的 PDB 資料檔案。遷移程序會自動在目標上建立必要的子目錄結構。您只需要建立父目錄。

   儲存策略：考慮為 /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，請列出所有 PDBs及其狀態：

   範例

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

   預期的輸出 (1 個 PDB 名為 ORCLDB 的範例）：

   範例

   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 或具有 PDBs)

3. 從來源資料庫建立密碼檔案和參數檔案

4. 將密碼檔案和參數檔案複製到目標 EC2 執行個體

5. 驗證來源資料庫是否以封存日誌模式執行

6. 在 RDS Custom 資料庫伺服器上設定 tnsnames.ora

EC2 資料庫執行個體 （目標） 步驟：

1. 編輯 EC2 的參數檔案 （架構特定）

2. 在 EC2 上設定 tnsnames.ora

3. 設定 EC2 執行個體的環境

4. 在 EC2 上設定 Oracle 接聽程式

5. 在處於 NOMOUNT 狀態的 EC2 上啟動資料庫

RMAN 重複步驟：

1. 執行 RMAN 作用中重複

2. 開啟資料庫 （以及多租戶PDBs)

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 或具有 PDBs)

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. 開啟資料庫 （以及多租戶PDBs)

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. 如果您必須繼續進行不相符RUs，請在遷移後執行資料修補程式：

   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 組態更新 Runbook 和文件

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

1. 進行徹底的評估：

   開始遷移之前，請執行環境的全面評估：

   • 資料庫清查：記錄所有資料庫、其大小、架構 （非 CDB 與多租戶） 和相依性

   • 應用程式相依性：識別連線至資料庫的所有應用程式及其連線方法

   • 效能基準：擷取效能指標 (CPU、記憶體、I/O、網路） 以進行遷移後比較

   • 備份和復原需求：文件 RPO （復原點目標） 和 RTO （復原時間目標）

   • 合規要求：識別可能影響遷移的任何法規或合規要求

2. 選擇正確的 EC2 執行個體類型：

   根據您的工作負載特性選取 EC2 執行個體類型：

   工作負載類型	建議的執行個體系列	關鍵特性
   一般用途 OLTP	M6i、M6a、M7i	平衡運算、記憶體和網路
   記憶體密集型	R6i、R6a、R7i、X2idn	高memory-to-CPU比率
   運算密集	C6i、C6a、C7i	高 CPU 效能
   I/O 密集型	I4i、Im4gn	高本機 NVMe SSD 儲存體
   混合工作負載	M5、M5a、M5n	經濟實惠的平衡效能

   執行個體大小調整準則：

   • 從與 RDS Custom 執行個體相同的執行個體類別開始

   • 在測試遷移期間監控資源使用率

   • 考慮使用 AWS Compute Optimizer 進行建議

   • 規劃 20-30% 的成長和尖峰負載空間

3. 設計您的儲存架構：

   EBS 磁碟區類型：

   磁碟區類型	使用案例	效能	成本
   gp3	一般用途，大多數工作負載	高達 16，000 IOPS、1，000 MB/s	低
   io2 Block Express	關鍵任務、高效能	高達 256，000 IOPS、4，000 MB/s	高
   Io1	高效能資料庫	高達 64，000 IOPS、1，000 MB/s	中高
   gp2	傳統一般用途	高達 16，000 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. 建立復原計劃：

   一律有復原策略：

   • 在驗證期間保持執行 RDS Custom 執行個體 （建議 1-2 週）

   • 維護來源和目標的定期備份

   • 文件轉返程序，包括連線字串變更

   • 在非生產環境中測試轉返程序

   • 定義復原條件 （效能降級、資料不一致、應用程式錯誤）

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 執行個體