Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# RDS Kustom untuk akhir dukungan Oracle
<a name="RDS-Custom-for-Oracle-end-of-support"></a>

**catatan**  
Pemberitahuan akhir dukungan: Pada 31 Maret 2027, AWS akan mengakhiri dukungan untuk Amazon RDS Custom for Oracle. Setelah 31 Maret 2027, Anda tidak akan lagi dapat mengakses RDS Custom for Oracle console atau RDS Custom for Oracle resources. Untuk informasi selengkapnya, lihat [RDS Kustom untuk akhir dukungan Oracle](#RDS-Custom-for-Oracle-end-of-support).

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

Setelah mempertimbangkan dengan cermat, AWS telah membuat keputusan untuk menghentikan layanan Amazon RDS Custom for Oracle. Layanan ini akan dihentikan efektif **31 Maret** 2027. Panduan preskriptif ini menyediakan strategi migrasi terperinci untuk membantu Anda bermigrasi dari RDS Custom for Oracle ke database Oracle yang dikelola sendiri di Amazon Elastic Compute Cloud (Amazon EC2).

### Garis waktu utama
<a name="RDS-Custom-for-Oracle-end-of-support-key_timelines"></a>
+ **Dari 31 Maret 2026 hingga 31 Maret 2027**: Kami menyarankan Anda bermigrasi dari RDS Custom for Oracle ke menjalankan Oracle di EC2. Selama periode ini, Anda dapat terus menggunakan RDS Custom for Oracle dengan fitur dan dukungan yang ada.
+ **Setelah 31 Maret 2027**: Anda tidak akan lagi dapat menggunakan layanan RDS Custom for Oracle.

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

Panduan ini ditujukan untuk:
+ Administrator database yang bertanggung jawab atas migrasi database Oracle
+ Arsitek cloud merencanakan strategi migrasi
+ DevOps insinyur yang mengelola infrastruktur basis data
+ Manajer TI mengawasi proses migrasi

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

Sebelum Anda mulai, pastikan Anda memiliki:
+ Amazon RDS Custom aktif untuk instans Oracle yang menjalankan Oracle 19c Enterprise Edition
+ Izin AWS Identity and Access Management (IAM) yang sesuai untuk membuat dan mengelola instans EC2
+ Memahami arsitektur database Anda (CDB non-CDB atau multitenant dengan PDB)
+ Perencanaan konektivitas jaringan antara instance sumber dan target
+ Strategi Backup dan Recovery untuk Migrasi Anda

## Opsi migrasi
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options"></a>

Sebagai bagian dari proses migrasi, Anda dapat memilih salah satu dari dua opsi migrasi berdasarkan persyaratan bisnis dan kasus penggunaan:

### Opsi 1: Duplikasi Aktif RMAN (Migrasi) Online/Offline
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options-RMAN"></a>

**Paling cocok untuk**
+ Beban kerja yang mampu membayar downtime yang direncanakan selama pemotongan akhir
+ Persyaratan migrasi yang lebih sederhana dengan bagian yang bergerak lebih sedikit
+ Database tempat Anda menginginkan migrasi satu kali yang mudah
+ Skenario di mana Anda tidak memerlukan sinkronisasi berkelanjutan sebelum cutover

**Karakteristik utama**
+ **Downtime: Waktu** henti minimal selama cutover akhir (database tetap online selama duplikasi, waktu henti singkat untuk pemotongan akhir)
+ **Kompleksitas**: Kompleksitas yang lebih rendah dengan duplikasi database langsung
+ **Durasi**: Waktu migrasi tergantung pada ukuran database dan bandwidth jaringan
+ **Fallback**: Membutuhkan pemeliharaan database sumber hingga validasi selesai
+ **Kemampuan online**: Database sumber tetap online dan dapat diakses selama proses duplikasi

**Pendekatan migrasi:** Duplikasi aktif RMAN membuat salinan persis dari database sumber pada target dengan menyalin file database melalui jaringan dari database sumber langsung yang berjalan. Database sumber tetap online dan dapat diakses oleh aplikasi selama proses duplikasi. Untuk database multitenant, RMAN secara otomatis menduplikasi seluruh CDB termasuk`CDB$ROOT`,`PDB$SEED`, dan semua database pluggable dalam satu operasi. Hanya jendela cutover singkat yang diperlukan untuk mengarahkan aplikasi ke instans EC2 baru.

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

**Paling cocok untuk**
+ Beban kerja produksi membutuhkan waktu henti minimal
+ Mission-critical database yang harus tetap tersedia
+ Skenario di mana Anda memerlukan sinkronisasi berkelanjutan sebelum cutover
+ Migrasi yang membutuhkan kemampuan fallback bawaan

**Karakteristik utama**
+ **Downtime**: Near-zero downtime (detik hingga menit untuk peralihan)
+ **Kompleksitas**: Kompleksitas yang lebih tinggi dengan konfigurasi Data Guard
+ **Durasi**: Waktu penyiapan awal ditambah sinkronisasi terus menerus hingga peralihan
+ **Fallback**: kemampuan Built-in mundur dengan menjaga sumber sebagai siaga

**Pendekatan migrasi:** Oracle Data Guard mempertahankan database siaga yang disinkronkan dengan terus mengirimkan dan menerapkan redo log dari database utama. Saat Anda siap menyelesaikan migrasi, Anda melakukan peralihan yang mempromosikan siaga EC2 ke primer dengan waktu henti minimal. Untuk database multitenant, Data Guard secara otomatis melindungi seluruh CDB termasuk semua PDB.

 **Matriks keputusan** 

Gunakan matriks berikut untuk membantu memilih opsi migrasi yang sesuai:


|  **Aspek**  |  **Duplikasi Aktif RMAN**  |  **Penjaga Data Oracle**  | 
| --- | --- | --- | 
| **Ketersediaan basis data sumber** | Online selama duplikasi | Online selama seluruh proses | 
| **Downtime yang dapat diterima** | Menit hingga jam (cutover akhir) | Detik ke menit (peralihan) | 
| **Kompleksitas migrasi** | Lebih rendah | Lebih tinggi | 
| **Sinkronisasi berkelanjutan** | Tidak | Ya | 
| **Kemampuan mundur** | Manual (simpan sumber) | Built-in (otomatis) | 
| **Pengujian sebelum cutover** | Terbatas | Pengujian penuh dimungkinkan | 
| **Persyaratan bandwidth jaringan** | Tinggi selama duplikasi | Sedang (terus menerus) | 
| **Terbaik untuk** | Sebagian besar migrasi, dev/test, pemotongan yang direncanakan | Produksi, mission-critical, downtime mendekati nol | 

### Pertimbangan arsitektur
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options-architecture-considerations"></a>

Kedua opsi migrasi mendukung dua arsitektur database Oracle:

 **Non-CDB** 

Database Oracle single instance tradisional tanpa arsitektur multitenant. Database ini:
+ Memiliki satu contoh database
+ Jangan gunakan database pluggable (PDB)
+ Lebih mudah untuk mengelola dan bermigrasi
+ Biasanya bernama ORCL di RDS Custom untuk Oracle

 **Multitenant (CDB dengan PDB)** 

Database kontainer (CDB) menghosting beberapa database pluggable (PDB), diperkenalkan di Oracle 12c. Database ini:
+ Memiliki database kontainer (CDB) dengan `CDB$ROOT` dan `PDB$SEED`
+ Host satu atau lebih database pluggable (PDB)
+ Menyediakan konsolidasi basis data dan isolasi sumber daya
+ Biasanya bernama RDSCDB di RDS Kustom untuk Oracle
+ Gunakan Oracle Managed Files (OMF) dengan GUID-based subdirektori untuk file data PDB

**Catatan penting untuk migrasi multitenant**: Basis data target akan diubah namanya menjadi ORCL selama proses migrasi (sumber: RDSCDB → target: ORCL). Ini menyederhanakan konfigurasi target dan menyelaraskan dengan konvensi penamaan standar.

 **Perbedaan utama dalam pendekatan migrasi** 


|  **Aspek**   |  **Non-CDB**  |  **Multitenant (CDB dengan PDB)**  | 
| --- | --- | --- | 
| **Ruang lingkup migrasi** | Database tunggal | Seluruh CDB dengan semua PDB | 
| **Post-migration negara**  | Database buka BACA TULIS | CDB buka BACA TULIS; PDB dalam status MOUNTED | 
| **Manajemen PDB** | N/A | Harus membuka PDB dan mengkonfigurasi auto-open | 
| **Pembersihan** | Database tunggal | CDB$ROOT(kaskade ke PDB); menangani C \#\# pengguna umum | 
| **Koneksi aplikasi** | Layanan basis data | Layanan PDB (bukan CDB) | 
| **File parameter** | Parameter standar | Membutuhkan ENABLE\_PLUGGABLE\_DATABASE=True | 
| **Kompleksitas** | Lebih rendah | Lebih tinggi karena banyak kontainer | 

## Prasyarat umum untuk kedua opsi migrasi
<a name="RDS-Custom-for-Oracle-end-of-support-common-prerequisites"></a>

Sebelum memulai salah satu opsi migrasi, selesaikan langkah-langkah prasyarat berikut:

1. Luncurkan dan konfigurasikan instans EC2

   Luncurkan instans EC2 dengan pertimbangan berikut:
   + **Jenis instans**: Pilih jenis instans EC2 yang memenuhi persyaratan sumber daya beban kerja Anda. Menggunakan kelas instance yang sama dengan instance RDS Custom Anda adalah titik awal yang baik. Pertimbangkan memori, CPU, dan persyaratan bandwidth jaringan.
   + **Sistem operasi**: Oracle Linux atau Red Hat Enterprise Linux (cocok atau kompatibel dengan versi OS Kustom RDS Anda)
   + **Perangkat lunak Oracle**: Instal perangkat lunak Oracle Database (versi mayor yang sama, versi minor, Pembaruan Rilis, dan idealnya tambalan satu kali yang sama dengan RDS Custom). Pastikan perangkat lunak Oracle diinstal di u01/app //oracle/atau lokasi pilihan Anda.
   + **Penyimpanan**: Konfigurasikan volume Amazon EBS dengan ukuran dan IOPS yang sesuai untuk memenuhi persyaratan beban kerja Anda. Pertimbangkan untuk menggunakan volume gp3 untuk kinerja hemat biaya atau io2 Block Express untuk beban kerja berkinerja tinggi.

1. Konfigurasikan arsitektur penyimpanan

   1. Penyimpanan sistem file (direkomendasikan untuk sebagian besar skenario)
      + Gunakan direktori sistem file standar untuk file data Oracle
      + Lebih mudah dikelola dan cocok untuk sebagian besar beban kerja
      + Panduan ini menggunakan contoh penyimpanan sistem file

   1. Manajemen Penyimpanan Otomatis Oracle (ASM)
      + Jika beban kerja Anda memerlukan ASM, instal dan konfigurasikan ASM mandiri pada instans EC2
      + Sesuaikan semua parameter jalur dalam file init sesuai untuk menggunakan grup disk ASM (mis., \+DATA, \+FRA)
      + Proses migrasi serupa untuk ASM, dengan penyesuaian jalur

1. Mengatur mekanisme transfer file

   Buat mekanisme untuk mentransfer file antara instans RDS Custom dan EC2. Anda memiliki beberapa pilihan:

   1. Opsi A: Amazon S3 (direkomendasikan untuk sebagian besar skenario)
      + Buat bucket Amazon S3 atau gunakan bucket yang sudah ada
      + Instal dan konfigurasikan AWS CLI pada kedua instance
      + Untuk instruksi, lihat [Memulai dengan AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html).

   1. Opsi B: Langsung SCP/SFTP
      + Jika port SSH terbuka antar instance, Anda dapat mentransfer file secara langsung
      + Cococok untuk file kecil seperti file parameter dan file kata sandi

   1. Opsi C: Amazon EFS
      + Jika Anda sudah memasang Amazon EFS di kedua instans, Anda dapat menggunakannya sebagai sistem file bersama
      + Cocokkan untuk lingkungan dengan infrastruktur EFS yang ada

      Panduan ini menggunakan Amazon S3 sebagai contoh, tetapi Anda dapat menyesuaikan perintah untuk metode yang Anda pilih.

1. Konfigurasikan konektivitas jaringan

   Pastikan konektivitas jaringan antara instans RDS Custom dan EC2:
   + **VPC yang sama**: Grup keamanan harus mengizinkan lalu lintas dua arah pada port pendengar Oracle (default 1521, atau port khusus Anda)
   + **VPC yang berbeda (akun yang sama)**: Siapkan peering VPC dan konfigurasikan tabel rute dan grup keamanan
   + **Akun berbeda**: Siapkan VPC mengintip di seluruh akun atau gunakan Transit Gateway AWS 
   + **Verifikasi konektivitas**: Gunakan ping dan telnet untuk menguji konektivitas pada port database

1. Buat struktur direktori di EC2

   Struktur direktori tergantung pada arsitektur database Anda:  
**Example Untuk Non-CDB:**  

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

   ```
   # 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
   ```
**catatan**  
RDS Custom for Oracle menggunakan Oracle Managed Files (OMF) untuk file data PDB dengan GUID-based subdirektori (misalnya,). `/rdsdbdata/db/pdb/RDSCDB_A/{{{GUID}}}/datafile/` Proses migrasi akan secara otomatis membuat struktur subdirektori yang diperlukan pada target. Anda hanya perlu membuat direktori induk.

   **Strategi penyimpanan**: Pertimbangkan untuk menggunakan volume EBS terpisah untuk/u01/app/oracle/backup untuk dengan mudah melepaskan dan menghapusnya setelah migrasi selesai, membebaskan biaya penyimpanan.

1. Verifikasi konfigurasi basis data sumber

Sebelum memulai migrasi, verifikasi konfigurasi basis data sumber Anda:

1. Masuk ke host database Kustom RDS sebagai pengguna rdsdb dan atur lingkungan:  
**Example**  

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

1. Connect ke database dan periksa arsitektur:  
**Example**  

   ```
   sqlplus / as sysdba
   SQL> SELECT name, cdb, open_mode, log_mode FROM v$database;
   ```  
**Example Untuk Non-CDB, output yang diharapkan**  

   ```
   NAME CDB OPEN_MODE                 LOG_MODE
   --------- --- -------------------- ------------
   ORCL NO  READ  WRITE               ARCHIVELOG
   ```  
**Example Untuk Multitenant (CDB), output yang diharapkan:**  

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

1. **Jika Anda memiliki CDB multitenant, daftarkan semua PDB** dan statusnya:  
**Example**  

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

   Output yang diharapkan (contoh dengan 1 PDB bernama ORCLDB):  
**Example**  

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

1. Periksa ukuran database total:  
**Example Untuk Non-CDB:**  

   ```
   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM dba_data_files;
   ```  
**Example Untuk 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;
   ```

## Opsi 1: Migrasi Fisik Menggunakan Duplikasi Aktif RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1"></a>

**Topics**
+ [Kapan menggunakan duplikasi aktif RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-when-to-use)
+ [Ikhtisar duplikasi aktif RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-overview)
+ [Alur kerja migrasi untuk duplikasi aktif RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-migration-workflow)
+ [Langkah 1: Jeda otomatisasi Amazon RDS Kustom](#RDS-Custom-for-Oracle-end-of-support-option-1-step-1)
+ [Langkah 2: Buat file kata sandi dan parameter](#RDS-Custom-for-Oracle-end-of-support-option-1-step-2)
+ [Langkah 3: Transfer file ke EC2](#RDS-Custom-for-Oracle-end-of-support-option-1-step-3)
+ [Langkah 4: Edit file parameter pada EC2](#RDS-Custom-for-Oracle-end-of-support-option-1-step-4)
+ [Langkah 5: Konfigurasikan TNS dan pendengar](#RDS-Custom-for-Oracle-end-of-support-option-1-step-5)
+ [Langkah 6: Mulai database `NOMOUNT` di EC2](#RDS-Custom-for-Oracle-end-of-support-option-1-step-6)
+ [Langkah 7: Lakukan duplikasi aktif RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-step-7)
+ [Langkah 8: Buka PDB (hanya multitenant)](#RDS-Custom-for-Oracle-end-of-support-option-1-step-8)
+ [Langkah 9: Hapus objek Kustom RDS](#RDS-Custom-for-Oracle-end-of-support-option-1-step-9)
+ [Langkah 10: Konfigurasikan startup otomatis](#RDS-Custom-for-Oracle-end-of-support-option-1-step-10)
+ [Langkah 11: Validasi akhir](#RDS-Custom-for-Oracle-end-of-support-option-1-step-11)

Bagian ini memberikan langkah-langkah rinci untuk memigrasi database Oracle Anda dari RDS Custom untuk Oracle ke EC2 menggunakan duplikasi aktif RMAN. Metode ini menduplikasi dari database hidup yang berjalan, menjaga sumber tetap online dan dapat diakses selama proses migrasi.

### Kapan menggunakan duplikasi aktif RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-when-to-use"></a>

Pilih duplikasi aktif RMAN saat:
+ Anda ingin menyimpan database sumber online dan dapat diakses selama migrasi
+ Anda dapat membeli jendela cutover singkat untuk pengalihan aplikasi akhir
+ Anda menginginkan proses migrasi langsung dengan lebih sedikit bagian yang bergerak
+ Ukuran database dan bandwidth jaringan Anda memungkinkan waktu duplikasi yang wajar
+ Anda tidak perlu sinkronisasi terus menerus sebelum cutover
+ Anda memigrasikan basis data produksi, pengembangan, atau pengujian

### Ikhtisar duplikasi aktif RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-overview"></a>

Duplikasi aktif RMAN tidak memerlukan cadangan database sumber atau mengambil database sumber offline. Ini menduplikasi database sumber langsung dan berjalan ke tujuan dengan menyalin file database melalui jaringan sementara sumber tetap online dan dapat diakses oleh aplikasi.

**Keuntungan utama:**
+ **Sumber tetap online**: Aplikasi dapat terus mengakses database sumber selama duplikasi
+ **Tidak diperlukan cadangan**: Menghilangkan kebutuhan akan penyimpanan cadangan menengah
+ **Transfer jaringan langsung**: File database disalin langsung dari sumber ke target
+ **Konsistensi otomatis**: RMAN memastikan database duplikat konsisten
+ **Operasi tunggal**: Untuk multitenant, duplikat seluruh CDB termasuk semua PDB dalam satu operasi

Proses duplikasi membuat salinan persis dari database sumber pada target, termasuk semua file data, file kontrol, dan redo log. Database sumber terus melayani permintaan aplikasi selama proses duplikasi. Hanya jendela cutover singkat yang diperlukan di bagian akhir untuk mengarahkan aplikasi dari sumber ke target.

**Garis waktu yang khas**

1. **Fase duplikasi** (sumber tetap online): 30 menit hingga beberapa jam tergantung pada ukuran database

1. **Fase validasi** (sumber tetap online): Jam hingga hari sesuai kebutuhan

1. **Fase cutover** (downtime singkat): Menit untuk mengarahkan aplikasi ke EC2

### Alur kerja migrasi untuk duplikasi aktif RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-migration-workflow"></a>

**Langkah-langkah instans (sumber) RDS Custom DB:**

1. Jeda otomatisasi kustom Amazon RDS

1. Verifikasi arsitektur database (non-CDB atau CDB dengan PDB)

1. Buat file kata sandi dan file parameter dari database sumber

1. Salin file kata sandi dan file parameter ke instans EC2 target

1. Verifikasi database sumber berjalan dalam mode log arsip

1. Konfigurasikan tnsnames.ora di server DB Kustom RDS

**Langkah-langkah instans EC2 DB (target):**

1. Edit file parameter untuk EC2 (khusus arsitektur)

1. Konfigurasikan tnsnames.ora di EC2

1. Konfigurasikan lingkungan untuk instans EC2

1. Konfigurasikan Oracle Listener di EC2

1. Mulai database pada EC2 dalam status NOMOUNT

**Langkah-langkah duplikasi RMAN:**

1. Lakukan duplikasi aktif RMAN

1. Buka database (dan PDB untuk multitenant)

1. Konfigurasikan PDB auto-open (hanya multitenant)

1. Hapus pengguna dan objek khusus RDS Kustom

1. Buat SPFILE dan konfigurasikan startup otomatis

1. Lanjutkan Amazon RDS Otomatisasi kustom pada sumber (jika tetap aktif)

### Langkah 1: Jeda otomatisasi Amazon RDS Kustom
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-1"></a>

Jeda mode otomatisasi pada instans Kustom RDS Anda sebelum melanjutkan dengan langkah-langkah migrasi untuk memastikan otomatisasi tidak mengganggu aktivitas RMAN. Parameter --resume-full-automation-mode-minute (240 menit = 4 jam dalam contoh ini) harus disesuaikan berdasarkan ukuran database Anda dan waktu duplikasi yang diharapkan.

**Penting**: Menjeda otomatisasi tidak memengaruhi ketersediaan database. Basis data tetap online dan dapat diakses oleh aplikasi selama proses duplikasi.

**Example**  

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

Validasi status otomatisasi:

**Example**  

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

Output yang diharapkan: "`all-paused`”

### Langkah 2: Buat file kata sandi dan parameter
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-2"></a>

Buat file kata sandi menggunakan`orapwd`. Ambil kata sandi SYS dari AWS Secrets Manager (disimpan selama pembuatan instance RDS Custom).

**Example**  

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

Buat file parameter dari database sumber:

**Example**  

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

File parameter yang dihasilkan akan berisi Custom-specific jalur dan parameter RDS. Untuk multitenant, parameter utama meliputi:
+ `enable_pluggable_database`= `TRUE` (penting untuk multitenant)
+ `noncdb_compatible`= `TRUE` (untuk kompatibilitas mundur)
+ Jalur file data untuk`CDB$ROOT`,`PDB$SEED`, dan semua PDB
+ `db_create_file_dest`dan `db_create_online_log_dest_1` untuk OMF

### Langkah 3: Transfer file ke EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-3"></a>

Pilih metode transfer file pilihan Anda. Panduan ini menggunakan Amazon S3 sebagai contoh.

 **Menggunakan Amazon S3:** 

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

**Example Untuk Non-CDB:**  

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

**Example Untuk Multitenant**  

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

Validasi file di EC2:

**Example**  

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

### Langkah 4: Edit file parameter pada EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-4"></a>

File parameter memerlukan pengeditan yang cermat untuk memastikan migrasi berhasil. Ini adalah salah satu langkah paling penting dalam proses migrasi.

Edit `$ORACLE_HOME/dbs/initORCL.ora` pada instans EC2 dan buat perubahan penting ini:

1. **Perbarui nama database**: Untuk multitenant, ubah semua kemunculan RDSCDB ke ORCL

1. **Konversi jalur Kustom RDS ke jalur EC2: Ganti/rdsdbdata/dengan**//oracle/u01/app

1. 

**Hapus parameter RDS Custom-specific**
   + `dg_broker_config_file1`dan `dg_broker_config_file2` (jika ada - menunjukkan ada replika)
   + `standby_file_management`(jika ada)
   + `spfile`(kami akan membuat SPFILE baru nanti)
   + `log_archive_dest`Parameter apa pun yang menunjuk ke tujuan siaga (simpan hanya `log_archive_dest_1` untuk pengarsipan lokal)

1. **Tambahkan parameter konversi nama file** (lihat di bawah)

1. **Sesuaikan parameter memori** berdasarkan ukuran instans EC2 Anda (opsional tetapi disarankan)

**Memahami parameter konversi nama file:** 

`LOG_FILE_NAME_CONVERT`Parameter `DB_FILE_NAME_CONVERT` dan sangat penting untuk duplikasi RMAN. Mereka memberi tahu RMAN cara memetakan jalur file sumber ke jalur file target selama proses duplikasi. Tanpa parameter ini, RMAN akan mencoba membuat file di jalur yang sama dengan sumbernya, yang akan gagal pada EC2.

**Pertimbangan utama:**
+ Setiap parameter menerima pasangan string: jalur sumber diikuti oleh jalur target
+ Beberapa pasangan dapat ditentukan dalam satu parameter
+ Untuk multitenant, Anda harus memetakan jalur untuk`CDB$ROOT`,`PDB$SEED`, dan semua PDB
+ Urutan pasangan penting - RMAN memprosesnya dalam urutan yang ditentukan
+ Jalur peka huruf besar/kecil dan harus sama persis

**Pemetaan jalur:**


**Non-CDB:**  

|  **Jalur kustom RDS**  |  **Jalur EC2**  |  **Deskripsi**  | 
| --- | --- | --- | 
| /rdsdbbin | /u01/app/oracle | Basis Oracle | 
| /rdsdbdata/db/ORCL\_A/datafile/ | /u01/app/oracle/oradata/ORCL/datafile/ | File data | 
| /rdsdbdata/db/ORCL\_A/controlfile/ | /u01/app/oracle/oradata/ORCL/controlfile/ | File kontrol | 
| /rdsdbdata/db/ORCL\_A/onlinelog/ | /u01/app/oracle/oradata/ORCL/onlinelog/ | Log pengulangan online | 
| /rdsdbdata/db/ORCL\_A/arch/ | /u01/app/oracle/oradata/ORCL/arch/ | Log arsip | 
| /rdsdbdata/admin/ORCL/adump | /u01/app/oracle/admin/ORCL/adump | Pembuangan audit | 
| /rdsdbdata/log | /u01/app/oracle | Tujuan diagnostik | 


**Multi-penghuni**  

|  **Jalur kustom RDS**  |  **Jalur EC2**  |  **Deskripsi**  | 
| --- | --- | --- | 
| /rdsdbbin | /u01/app/oracle | Basis Oracle | 
| /rdsdbdata/db/cdb/RDSCDB/datafile/ | /u01/app/oracle/oradata/ORCL/cdb/datafile/ | File data root CDB | 
| /rdsdbdata/db/cdb/pdbseed/ | /u01/app/oracle/oradata/ORCL/pdbseed/datafile/ | PDB$SEEDfile data | 
| /rdsdbdata/db/pdb/RDSCDB\_A/ | /u01/app/oracle/oradata/ORCL/pdb/datafile/ | File data PDB (OMF dengan GUID) | 
| /rdsdbdata/db/cdb/RDSCDB\_A/controlfile/ | /u01/app/oracle/oradata/ORCL/controlfile/ | File kontrol | 
| /rdsdbdata/db/cdb/RDSCDB\_A/onlinelog/ | /u01/app/oracle/oradata/ORCL/onlinelog/ | Log pengulangan online | 
| /rdsdbdata/db/cdb/RDSCDB\_A/arch/redolog | /u01/app/oracle/oradata/ORCL/arch/ | Log arsip | 
| /rdsdbdata/admin/RDSCDB/adump | /u01/app/oracle/admin/ORCL/adump | Pembuangan audit | 
| /rdsdbdata/log | /u01/app/oracle | Tujuan diagnostik | 

**Tambahkan parameter konversi:**

**Example Non-CDB:**  

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

**Example **Multitenant** (harus menyertakan pemetaan untuk root CDB`PDB$SEED`, dan semua jalur PDB):**  

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

**Penting**: Untuk multitenant, pastikan `enable_pluggable_database` = `TRUE` ada dalam file parameter. RDS Custom menggunakan OMF untuk file data PDB dengan GUID-based subdirektori - pemetaan jalur menangani ini secara otomatis.

 **Contoh file parameter lengkap:** 

**Example Contoh file Non-CDB parameter (`initORCL.ora`):**  

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

**Example Contoh file parameter Multitenant (): `initORCL.ora`**  

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

**Penjelasan parameter kunci:**
+ `enable_pluggable_database=TRUE`: Diperlukan untuk CDB multitenant. Parameter ini memungkinkan fitur database pluggable.
+ `noncdb_compatible=TRUE`: Ditetapkan oleh RDS Custom untuk kompatibilitas mundur. Dapat disimpan atau dihapus berdasarkan kebutuhan Anda.
+ `db_create_file_dest`: Menentukan lokasi default untuk Oracle Managed Files (OMF). Untuk multitenant, ini menunjuk ke direktori datafile PDB.
+ `db_create_online_log_dest_1`: Menentukan lokasi untuk redo log online saat menggunakan OMF.
+ `DB_FILE_NAME_CONVERT`: Penting untuk duplikasi RMAN. Memetakan jalur file data sumber ke jalur target.
+ `LOG_FILE_NAME_CONVERT`: Peta sumber mengulang jalur log ke jalur target.
+ `memory_target`dan`memory_max_target`: Sesuaikan ini berdasarkan memori instans EC2 Anda. Nilai-nilai yang ditampilkan adalah contoh.
+ `processes`: Jumlah maksimum proses sistem operasi yang dapat terhubung ke Oracle. Sesuaikan berdasarkan beban kerja Anda.

**Pedoman ukuran memori:**

Saat menyesuaikan parameter memori untuk instans EC2 Anda:


|  **Memori Instans EC2**  |  **Memory\_target yang direkomendasikan**  |  **Direkomendasikan memory\_max\_target**  | 
| --- | --- | --- | 
| 16 GB | 12 GB (12884901888 byte) | 14 GB (15032385536 byte) | 
| 32 GB | 24 GB (25769803776 byte) | 28 GB (30064771072 byte) | 
| 64 GB | 48 GB (51539607552 byte) | 56 GB (60129542144 byte) | 
| 128 GB | 96 GB (103079215104 byte) | 112 GB (120259084288 byte) | 

Sisakan sekitar 20-25% dari memori sistem untuk sistem operasi dan proses lainnya.

### Langkah 5: Konfigurasikan TNS dan pendengar
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-5"></a>

Pada kedua contoh, tambahkan entri TNS ke: `tnsnames.ora`

**Example Non-CDB:**  

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

**Example Multitenant:**  

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

**Example Konfigurasikan listener pada EC2 ()`$ORACLE_HOME/network/admin/listener.ora`:**  

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

**Example Mulai pendengar:**  

```
lsnrctl start
```

**catatan**  
Untuk duplikasi aktif RMAN, entri TNS terhubung ke instance database menggunakan SID (bukan SERVICE\_NAME). Untuk multitenant, ini terhubung ke CDB, dan RMAN secara otomatis menduplikasi semua PDB.

### Langkah 6: Mulai database `NOMOUNT` di EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-6"></a>

**Example**  

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

sqlplus / as sysdba

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

**Example Verifikasi parameter:**  

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

### Langkah 7: Lakukan duplikasi aktif RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-7"></a>

Duplikasi aktif RMAN menyalin database dari sumber langsung yang berjalan ke target. Database sumber tetap online dan dapat diakses oleh aplikasi selama proses ini.

Connect RMAN ke instans sumber dan target:

**Example**  

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

**Example Output yang diharapkan untuk non-CDB:**  

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

**Example Output yang diharapkan untuk multitenant:**  

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

**Example Jalankan perintah duplikasi aktif:**  

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

**catatan**  
**Sumber tetap online**: Database sumber terus melayani permintaan aplikasi selama duplikasi
**Untuk non-CDB**: Ini menduplikasi seluruh database saat tetap online
**Untuk multitenant**: Ini menduplikasi seluruh CDB termasuk`CDB$ROOT`,`PDB$SEED`, dan semua PDB dalam satu operasi sementara sumbernya tetap online
**NOFILENAMECHECK**: Memungkinkan RMAN untuk melanjutkan meskipun nama file berbeda antara sumber dan target
**Durasi**: Tergantung pada ukuran database dan bandwidth jaringan. Untuk database 100GB, harapkan 30-60 menit
**Dampak jaringan:** Penggunaan bandwidth jaringan yang tinggi selama duplikasi, tetapi basis data sumber tetap dapat diakses

**Proses duplikasi aktif RMAN mencakup beberapa fase:**

1. Menghubungkan ke basis data sumber dan target

1. Membuat `SPFILE` dari memori pada target

1. Mengembalikan file kontrol ke target

1. Memasang basis data target

1. Menyalin semua file data dari sumber ke target melalui jaringan (sumber tetap online)

1. Memulihkan basis data target

1. Membuka database target dengan `RESETLOGS`

**Selama duplikasi, database sumber:**
+ Tetap dalam `READ WRITE` mode
+ Terus menerima koneksi
+ Memproses transaksi secara normal
+ Menghasilkan redo log secara normal
+ Sepenuhnya dapat diakses oleh aplikasi

**Example Pantau kemajuan di sesi lain:**  

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

 **Pemantauan dan pemecahan masalah terperinci selama duplikasi RMAN:** 

Saat duplikasi RMAN sedang berjalan, Anda dapat memantau kemajuannya menggunakan beberapa metode:

1. **Pantau keluaran RMAN:**

   Sesi RMAN akan menampilkan informasi kemajuan terperinci termasuk:
   + Alokasi saluran
   + Kemajuan salinan data
   + Perkiraan waktu penyelesaian
   + Byte diproses

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

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

1.  **Pantau operasi yang berjalan lama:**   
**Example Dalam sesi SQL\* Plus terpisah pada instans EC2 target:**  

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

**Kueri ini menunjukkan:**
   + `opname`: Nama operasi (misalnya, “RMAN: pemulihan data lengkap”)
   + `sofar`: Blok diproses sejauh ini
   + `totalwork`: Total blok untuk diproses
   + `pct_complete`: Persentase selesai
   + `time_remaining`: Perkiraan detik tersisa
   + `elapsed_seconds`: Waktu berlalu sejauh ini

1. **Memantau saluran RMAN:**  
**Example**  

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

1. **Periksa log peringatan:**  
**Example Pada instans EC2 target, pantau log peringatan untuk setiap kesalahan atau peringatan:**  

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

**Masalah umum selama duplikasi RMAN:**
   + **Batas waktu jaringan**

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

     **Solusi**: Tingkatkan nilai batas waktu jaringan `sqlnet.ora` pada kedua instance:

     ```
     SQLNET.RECV_TIMEOUT=600
     SQLNET.SEND_TIMEOUT=600
     ```
   + **Tidak cukup ruang pada target**

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

     **Solusi**: Periksa ruang yang tersedia dan tambahkan lebih banyak kapasitas volume EBS:

     ```
     df -h /u01/app/oracle/oradata
     ```
   + **Kesalahan file parameter**

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

     **Solusi**: Verifikasi semua direktori dalam file parameter ada dan memiliki izin yang tepat.
   + **Ketidakcocokan file kata sandi**

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

     **Solusi**: Pastikan file kata sandi pada target cocok dengan sumber dan memiliki nama yang benar (`orapwORCL`).

### Langkah 8: Buka PDB (hanya multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-8"></a>

Setelah duplikasi RMAN selesai, CDB pada EC2 terbuka dalam `READ WRITE` mode, tetapi semua PDB dalam keadaan. `MOUNTED` Ini adalah perilaku yang diharapkan - Anda harus membukanya secara manual.

Periksa status PDB saat ini:

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

Output yang diharapkan (contoh dengan satu PDB bernama`ORCLDB`):

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

Buka semua PDB:

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

Verifikasi semua PDB sekarang terbuka dalam `READ WRITE` mode:

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

Keluaran yang diharapkan

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

Konfigurasikan buka otomatis saat startup menggunakan metode save state (direkomendasikan untuk Oracle 19c):

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

Ini memberitahu Oracle untuk mengingat keadaan terbuka PDB saat ini dan mengembalikannya pada startup CDB.

Verifikasi status tersimpan:

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

Verifikasi layanan PDB terdaftar dengan pendengar:

```
lsnrctl services
```

Output yang diharapkan harus menunjukkan layanan untuk CDB dan setiap PDB. Jika layanan tidak ditampilkan:

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

Kemudian periksa lagi dengan`lsnrctl services`.

### Langkah 9: Hapus objek Kustom RDS
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-9"></a>

Karena ini sekarang database yang dikelola sendiri di EC2, Anda harus menghapus Custom-specific pengguna dan objek RDS. Proses pembersihan berbeda antara arsitektur non-CDB dan multitenant.

**penting**  
Sebelum menjatuhkan RDS-specific pengguna dan ruang tabel, verifikasi bahwa tidak ada objek aplikasi di bawah skema ini:

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

Jika ada objek aplikasi yang ditemukan, migrasikan ke skema aplikasi yang sesuai sebelum melanjutkan.

**Example Non-CDB:**  

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

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

Output yang diharapkan: `no rows selected`

**Multitenant:**

Dalam lingkungan multitenant, RDS Custom membuat pengguna umum `CDB$ROOT` yang terlihat di semua PDB. Anda harus membersihkan dari`CDB$ROOT`.

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

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

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

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

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

Output yang diharapkan untuk semua kueri: `no rows selected`

### Langkah 10: Konfigurasikan startup otomatis
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-10"></a>

Buat`SPFILE`:

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

Untuk multitenant, pastikan PDB terbuka:

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

Sunting`/etc/oratab`:

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

### Langkah 11: Validasi akhir
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-11"></a>

**Example Non-CDB:**  

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

**Example Multitenant:**  

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

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

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

 **Langkah 12: Lanjutkan otomatisasi kustom RDS** 

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

 

## Opsi 2: Migrasi Fisik Menggunakan Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2"></a>



Bagian ini memberikan langkah-langkah rinci untuk memigrasi database Oracle Anda dari RDS Custom untuk Oracle ke EC2 menggunakan Oracle Data Guard. Metode ini cocok untuk migrasi yang membutuhkan waktu henti minimal.

### Kapan menggunakan Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-when-use-odg"></a>

**Pilih Oracle Data Guard saat:**
+ Anda memerlukan waktu henti minimal (detik hingga menit untuk peralihan)
+ Anda memigrasikan basis data produksi atau mission-critical
+ Anda perlu sinkronisasi terus menerus sebelum cutover
+ Anda menginginkan kemampuan fallback bawaan
+ Anda perlu menguji database target sebelum melakukan migrasi

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

Oracle Data Guard mempertahankan database siaga yang disinkronkan dengan terus mengirimkan dan menerapkan redo log dari database utama. Saat Anda siap menyelesaikan migrasi, Anda melakukan peralihan yang mempromosikan siaga EC2 ke primer dengan waktu henti minimal (detik hingga menit). Untuk database multitenant, Data Guard secara otomatis melindungi seluruh CDB termasuk semua PDB. Redo yang dihasilkan oleh PDB apa pun dikirim ke siaga dan diterapkan ke PDB yang sesuai pada siaga.

### Alur kerja migrasi untuk Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-odg-workflow"></a>

**Langkah-langkah instans RDS Custom DB (utama):**

1. Jeda otomatisasi kustom Amazon RDS

1. Verifikasi arsitektur database (non-CDB atau CDB dengan PDB)

1. Konfirmasikan database utama berjalan dalam mode log arsip dan `FORCE_LOGGING` diaktifkan

1. Buat file kata sandi

1. Lakukan backup online RMAN dari database utama (atau gunakan duplikasi aktif)

1. Buat file parameter dari database sumber

1. Salin set cadangan, file parameter, dan file kata sandi ke instans EC2 target

**Langkah-langkah instans EC2 DB (siaga):**

1. Salin semua file dari sumber ke instans EC2

1. Salin file kata sandi ke instans EC2

1. Edit file parameter untuk EC2 (khusus arsitektur)

1. Buat file parameter server dari file parameter

1. Kembalikan file kontrol siaga dan database

**Langkah-langkah konfigurasi Data Guard:**

1. Konfigurasikan pendengar Oracle pada kedua instance

1. Konfigurasikan tnsnames.ora pada kedua instance

1. Mulai broker Oracle Data Guard pada kedua instance (opsional tetapi disarankan)

1. Aktifkan konfigurasi Oracle Data Guard

1. Konfigurasikan fal\_server dan fal\_client pada instance siaga EC2

1. Konfigurasikan file log redo siaga pada kedua instance

1. Pulihkan contoh siaga

1. Lakukan peralihan manual

1. Buka database (dan PDB untuk multitenant)

1. Konfigurasikan PDB auto-open (hanya multitenant)

1. Hapus pengguna dan objek khusus RDS Kustom

1. Buat SPFILE dan konfigurasikan startup otomatis

### Langkah 1: Jeda otomatisasi Amazon RDS Kustom
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-1"></a>

Jeda mode otomatisasi pada instans Kustom RDS Anda. `--resume-full-automation-mode-minute`Parameter harus disesuaikan berdasarkan ukuran database Anda dan waktu penyiapan Data Guard yang diharapkan.

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

Validasi status otomatisasi:

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

Output yang diharapkan: "`all-paused`”

### Langkah 2: Konfirmasikan mode log arsip dan `FORCE_LOGGING`
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-2"></a>

Oracle Data Guard mengharuskan database utama berada dalam mode log arsip dengan pencatatan paksa diaktifkan:

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

Keluaran yang diharapkan

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

Jika pencatatan paksa tidak diaktifkan, jalankan:

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

### Langkah 3: Buat file kata sandi dan parameter
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-3"></a>

Buat file kata sandi menggunakan`orapwd`. Ambil kata sandi SYS dari AWS Secrets Manager.

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

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

Buat file parameter dari database sumber:

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

### Langkah 4: Lakukan pencadangan RMAN atau gunakan duplikasi aktif
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4"></a>

Anda memiliki dua opsi untuk membuat database siaga:

#### Opsi A: Pencadangan online RMAN (direkomendasikan untuk sebagian besar skenario)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4-a"></a>

Buat direktori cadangan dan backup database:

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

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

**catatan**  
Untuk multitenant, kata kunci database mencadangkan seluruh CDB termasuk semua PDB secara otomatis.

#### Opsi B: Duplikasi aktif (metode alternatif)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4-b"></a>

Lewati langkah pencadangan dan gunakan duplikasi aktif RMAN untuk membangun siaga langsung melalui jaringan. Ini menghilangkan kebutuhan untuk penyimpanan cadangan dan transfer file. Setelah mengonfigurasi TNS dan pendengar (lihat di bawah), jalankan:

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

Panduan ini berfokus pada Opsi A (berbasis cadangan), tetapi Opsi B adalah alternatif yang valid.

### Langkah 5: Transfer file ke EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-5"></a>

Pilih metode transfer file pilihan Anda. Panduan ini menggunakan Amazon S3 sebagai contoh.

**Menggunakan Amazon S3:**

**Example Untuk Non-CDB:**  

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

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

**Example Untuk Multitenant:**  

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

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

### Langkah 6: Edit file parameter pada EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-6"></a>

Edit `$ORACLE_HOME/dbs/initORCL.ora` pada instans EC2 dan buat perubahan penting ini:

1. **Perbarui nama database**: Untuk multitenant, ubah semua kemunculan ke `RDSCDB` `ORCL`

1. **Ubah db\_unique\_name**: Dari (atau) menjadi `ORCL_A` `RDSCDB_A` `ORCL_B`

1. **Konversi jalur Kustom RDS ke jalur EC2: Ganti** dengan `/rdsdbdata/` `/u01/app/oracle/`

1. 

****Hapus parameter RDS Custom-specific****
   + `dg_broker_config_file1`dan `dg_broker_config_file2` (jika ada)
   + `standby_file_management`(jika ada)
   + `spfile`(kami akan membuat yang baru `SPFILE` nanti)
   + `log_archive_dest`Parameter apa pun yang menunjuk ke tujuan siaga

1. **Sesuaikan parameter memori** berdasarkan ukuran instans EC2 Anda (opsional tetapi disarankan)

 **Pemetaan jalur:** 

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

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

**Penting**: Untuk multitenant, pastikan `enable_pluggable_database` = `TRUE` ada dalam file parameter.

### Langkah 7: Buat `SPFILE` dan kembalikan database siaga
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-7"></a>

Mulai instance dan buat SPFILE:

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

Buat tautan simbolis:

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

Mulai instance dan pulihkan:

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

Jika file cadangan berada di jalur yang berbeda dari sumbernya, katalogkan terlebih dahulu:

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

Kembalikan file kontrol siaga dan pasang:

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

Jika jalur file data berbeda (misalnya, menggunakan ASM), gunakan`SET NEWNAME`:

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

Jika tidak, cukup pulihkan:

```
RMAN> restore database;
```

Pulihkan database ke urutan terakhir yang tersedia:

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

**catatan**  
Untuk multitenant, RMAN secara otomatis mengembalikan dan memulihkan semua PDB. Anda tidak perlu mengembalikan setiap PDB secara terpisah.

### Langkah 8: Konfigurasikan TNS dan pendengar
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-8"></a>

Pada kedua contoh, tambahkan entri TNS ke: `tnsnames.ora`

**Example Non-CDB:**  

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

**Example Multitenant:**  

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

Konfigurasikan pendengar pada kedua instance. Pada RDS Custom, tambahkan ke: `listener.ora`

**Example Untuk Non-CDB:**  

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

**Example Untuk Multitenant:**  

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

Mulai pendengar:

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

Di EC2, buat`$ORACLE_HOME/network/admin/listener.ora`:

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

Mulai pendengar:

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

**catatan**  
Anda dapat menggunakan listener yang ada di RDS Custom jika diinginkan, tetapi membuat pendengar Data Guard terpisah memberikan isolasi yang lebih baik.

**penting**  
Jika `tnsping` atau `listener` konektivitas gagal, periksa `iptables` aturan di EC2. Banyak instans EC2 Linux memiliki `iptables` aturan default yang memblokir port 1521. Tambahkan aturan: `sudo iptables -I INPUT 5 -p tcp --dport 1521 -j ACCEPT`

### Langkah 9: Aktifkan broker dan konfigurasi Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-9"></a>

Pada kedua contoh, aktifkan broker Data Guard:

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

Pada primer RDS Custom, sambungkan ke broker Data Guard dan buat konfigurasi:

```
dgmgrl /
```

**Example Untuk Non-CDB:**  

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

 

**Example Untuk Multitenant:**  

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

Setel pengidentifikasi koneksi statis dan aktifkan:

 

**Example Untuk Non-CDB:**  

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

 

**Example Untuk Multitenant:**  

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

**catatan**  
Broker Data Guard adalah opsional tetapi direkomendasikan untuk manajemen yang lebih mudah. Untuk migrasi sederhana, Anda dapat mengonfigurasi Data Guard secara manual tanpa broker.

**catatan**  
Saat Anda mengaktifkan Penjaga Data untuk CDB, secara otomatis melindungi semua PDB. Redo yang dihasilkan oleh PDB apa pun dikirim ke siaga dan diterapkan ke PDB yang sesuai pada siaga.

### Langkah 10: Konfigurasikan log redo siaga dan mulai pemulihan
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10"></a>

Pada instance siaga EC2, tambahkan file log redo siaga (n\+1 di mana n adalah jumlah grup log redo online):

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

**catatan**  
Untuk multitenant, log redo siaga dibuat di tingkat CDB dan dibagikan oleh semua PDB.

Konfigurasikan parameter FAL pada siaga:

 

**Example Untuk Non-CDB:**  

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

 

**Example Untuk Multitenant:**  

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

Mulai pemulihan terkelola:

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

Pantau lag penerapan:

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

**Pemantauan terperinci dan manajemen sinkronisasi Data Guard:**

Pemantauan Data Guard sangat penting untuk memastikan migrasi berhasil. Berikut adalah teknik pemantauan yang komprehensif:

1. **Pantau statistik Penjaga Data:**

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

   Metrik utama untuk dipantau:
   + transport lag: Perbedaan waktu antara saat redo dihasilkan pada primer dan diterima saat siaga
   + terapkan lag: Perbedaan waktu antara saat pengulangan dibuat dan diterapkan saat siaga
   + tingkat penerapan: Nilai di mana redo diterapkan () MB/sec
   + redo diterima: Total redo diterima dengan siaga
   + redo diterapkan: Total redo diterapkan dengan siaga

1. **Pantau pengiriman log arsip:**

   Pada primer (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';
   ```

   Pada siaga (EC2):

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

1. **Memantau proses pemulihan terkelola:**

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

1. **Monitor redo apply rate untuk multitenant:**

   Untuk database multitenant, pantau tarif penerapan per PDB:

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

1. **Pantau log pengulangan siaga:**

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

1. **Perkirakan penyelesaian sinkronisasi:**

   Hitung waktu yang tersisa berdasarkan tarif penerapan:

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

#### Masalah sinkronisasi Data Guard yang umum:
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues"></a>



##### Masalah 1: Kelambatan penerapan tinggi
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-1"></a>

Gejala:

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

Penyebab dan solusi:
+ **Tidak cukup CPU/IO saat siaga**: Tingkatkan jenis instans EC2 atau tingkatkan EBS IOPS
+ **Batasan bandwidth jaringan**: Gunakan jaringan yang ditingkatkan atau jenis instance bandwidth yang lebih tinggi
+ **Beberapa PDB dengan tingkat transaksi tinggi**: Pertimbangkan untuk meningkatkan redo apply parallelism (memerlukan lisensi Active Data Guard)

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

##### Masalah 2: Arsipkan celah log
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-2"></a>

Gejala:

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

Solusi:

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

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

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

##### Masalah 3: Ulangi kegagalan transportasi
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-3"></a>

Gejala:

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

Solusi:

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

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

##### Masalah 4: Pemulihan terkelola tidak menerapkan pengulangan
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-4"></a>

Gejala:

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

Solusi:

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

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

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

**Untuk Multitenant**, Anda juga dapat memeriksa status setiap PDB pada siaga:

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

Output yang diharapkan (PDB dalam `MOUNTED` keadaan siaga):

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

**catatan**  
Pada siaga fisik, PDB tetap dalam `MOUNTED` keadaan selama pemulihan terkelola.

### Langkah 11: Lakukan peralihan
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-11"></a>

Setelah Anda puas bahwa siaga sepenuhnya disinkronkan dan siap, lakukan peralihan. Untuk multitenant, switchover akan mengalihkan seluruh CDB (semua PDB) dari primer RDS Custom ke EC2 standby.

Pada instance utama RDS Custom, sambungkan ke broker Data Guard dan validasi kedua database siap untuk beralih:

**Example Untuk Non-CDB:**  

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

 

**Example Untuk Multitenant:**  

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

Keduanya harus menunjukkan `Ready for Switchover: Yes`

Beralih dari primer Kustom RDS ke siaga EC2:

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

Verifikasi bahwa switchover berhasil:

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

Instance EC2 (`ORCL_B`) sekarang menjadi database utama, dan instance RDS Custom adalah siaga fisik.

### Langkah 12: Buka PDB (hanya multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-12"></a>

Setelah peralihan, CDB pada EC2 terbuka dalam mode BACA TULIS, tetapi semua PDB dalam keadaan MOUNTED. Anda harus membukanya secara manual.

Connect ke primer baru di EC2:

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

Keluaran yang diharapkan

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

Periksa status PDB saat ini:

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

Output yang diharapkan (PDB dalam `MOUNTED` keadaan - contoh dengan satu PDB bernama`ORCLDB`):

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

Buka semua PDB:

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

Database pluggable diubah.

Verifikasi semua PDB sekarang terbuka dalam `READ WRITE` mode:

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

Keluaran yang diharapkan

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

### Langkah 13: Konfigurasikan PDB auto-open saat startup (hanya multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-13"></a>

Konfigurasikan PDB untuk terbuka secara otomatis ketika CDB mulai menggunakan metode save state (direkomendasikan untuk Oracle 19c):

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

Verifikasi status tersimpan:

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

Verifikasi layanan PDB terdaftar dengan pendengar:

```
lsnrctl services
```

Output yang diharapkan harus menunjukkan layanan untuk CDB dan setiap PDB. Jika layanan tidak ditampilkan:

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

Kemudian periksa lagi dengan`lsnrctl services`.

### Langkah 14: Hapus objek Kustom RDS
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-14"></a>

Karena ini sekarang database yang dikelola sendiri di EC2, Anda harus menghapus pengguna dan objek khusus RDS Custom. Proses pembersihan sedikit berbeda antara arsitektur non-CDB dan multitenant.

**penting**  
Sebelum menjatuhkan RDS-specific pengguna dan ruang tabel, verifikasi bahwa tidak ada objek aplikasi di bawah skema ini:

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

Jika ada objek aplikasi yang ditemukan, migrasikan ke skema aplikasi yang sesuai sebelum melanjutkan.

**Non-CDB pembersihan:**

```
sqlplus / as sysdba

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

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

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

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

Output yang diharapkan: `no rows selected`

**Pembersihan multitenant:**

Dalam lingkungan multitenant, RDS Custom membuat pengguna umum `CDB$ROOT` yang terlihat di semua PDB. Anda harus membersihkan dari`CDB$ROOT`.

```
sqlplus / as sysdba

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

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

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

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

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

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

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

Output yang diharapkan untuk semua kueri: tidak ada baris yang dipilih

### Langkah 15: Konfigurasikan startup otomatis
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-15"></a>

Verifikasi yang `SPFILE` sedang digunakan:

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

Jika `spfile` jalurnya benar, tidak ada tindakan yang diperlukan. Jika tidak, buat satu:

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

Mulai ulang database:

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

Untuk multitenant, buka semua PDB (harus terbuka otomatis jika Anda menyimpan status sebelumnya):

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

Jika PDB tidak terbuka, buka secara manual:

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

Sunting`/etc/oratab`:

```
vi /etc/oratab
```

Ubah baris untuk `ORCL` dari `N` ke`Y`:

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

### Langkah 16: Validasi akhir
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-16"></a>

Lakukan validasi komprehensif pada database yang dimigrasi.

**Example Untuk Non-CDB:**  

```
sqlplus / as sysdba

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

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

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

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

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

**Example Untuk Multitenant:**  

```
sqlplus / as sysdba

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

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

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

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

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

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

Test application connectivity:

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

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

Uji konektivitas aplikasi:

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

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

### Langkah 17: Bersihkan file cadangan
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-17"></a>

Setelah validasi berhasil, hapus file cadangan dan lepaskan volume cadangan jika menggunakan volume EBS terpisah:

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

Jika menggunakan volume EBS terpisah untuk backup:

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

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

### Langkah 18: Lanjutkan otomatisasi kustom RDS
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-18"></a>

Jika Anda berencana untuk menjaga instance RDS Custom tetap berjalan sebagai fallback selama periode validasi, lanjutkan otomatisasi:

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

## Memecahkan masalah umum
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting"></a>



Bagian ini mencakup masalah umum yang mungkin Anda temui selama migrasi untuk pendekatan duplikasi RMAN dan Oracle Data Guard, yang mencakup arsitektur non-CDB dan multitenant.

### ORA-09925: Tidak dapat membuat berkas jejak audit
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-09925"></a>

**Penyebab:** Direktori audit yang ditentukan dalam `audit_file_dest` parameter tidak ada pada instans EC2 target.

 **Solusi:** 

Pastikan direktori audit ada dan memiliki izin yang tepat:

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

### ORA-01261: String `db_create_file_dest` tujuan parameter tidak dapat diterjemahkan
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-01261"></a>

**Penyebab:** Direktori yang ditentukan dalam `db_create_file_dest` parameter tidak ada pada instans EC2 target.

 **Solusi:** 

Untuk non-CDB:

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

Untuk multitenant:

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

### ORA-01804: Kegagalan untuk menginisialisasi informasi zona waktu
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-01804"></a>

Kesalahan ini dapat terjadi saat menjatuhkan `RDSADMIN` pengguna jika sumber RDS memiliki versi zona waktu yang lebih tinggi daripada yang diinstal di EC2 $ORACLE\_HOME Anda.

 **Solusi:** 

1. Periksa versi zona waktu:

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

1. Sebagai solusinya, atur variabel lingkungan file zona waktu agar sesuai dengan yang tersedia $ORACLE\_HOME Anda:

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

   Sesuaikan nomor agar sesuai dengan versi yang tersedia di instalasi Anda.

1. Coba lagi drop:

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

### Cross-RU masalah migrasi (Pembaruan Rilis berbeda)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-cross-ru-migration"></a>

**Penyebab:** Instans EC2 target memiliki Pembaruan Rilis Oracle (RU) atau tambalan satu kali yang berbeda dari instans Kustom RDS sumber, menyebabkan kesalahan kompatibilitas selama atau setelah migrasi.

**Kesalahan umum:**
+ ORA-00600 kesalahan internal selama pengulangan berlaku (Data Guard)
+ ORA-39700 Database harus dibuka dengan `UPGRADE` pilihan
+ Inkonsistensi kamus setelah migrasi
+ Objek tidak valid di atau `DBA_REGISTRY` `DBA_OBJECTS`

 **Solusi:** 

 **Praktik terbaik - Cocokkan versi RU dan tambalan satu kali persis:** 

1. Periksa versi RU yang tepat pada sumber dan target:

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

1. Verifikasi level patch $ORACLE\_HOME:

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

1. Jika versi tidak cocok, sejajarkan sebelum migrasi dengan menerapkan atau memutar kembali tambalan sesuai kebutuhan.

1. Jika Anda harus melanjutkan dengan RU yang tidak cocok, jalankan datapatch setelah migrasi:

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

1. Periksa objek yang tidak valid dan kompilasi ulang:

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

### Masalah konektivitas jaringan
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-network-connectivity"></a>

 

**Penyebab:** Grup keamanan, ACL jaringan, atau `iptables` memblokir port pendengar Oracle.

 **Solusi:** 

1. Verifikasi grup keamanan mengizinkan port dua arah

1. Periksa iptables di EC2:

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

1. Tambahkan aturan jika diperlukan:

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

1. Uji konektivitas:

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

### PDB tidak dibuka setelah migrasi (hanya multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdbs-not-opening"></a>

**Penyebab:** Ini adalah perilaku yang diharapkan. Setelah duplikasi RMAN atau peralihan Data Guard, CDB terbuka tetapi PDB dalam keadaan. `MOUNTED`

 **Solusi:** 

Buka secara manual:

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

Jika PDB tertentu gagal dibuka, periksa log peringatan untuk kesalahan:

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

Penyebab umum termasuk file data yang hilang atau masalah pemetaan jalur.

### File data PDB tidak ditemukan atau jalur tidak cocok (hanya multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdb-data-files-not-found"></a>

**Penyebab:** Migrasi tidak memetakan semua jalur sumber dengan benar, terutama untuk file data OMF-based PDB.

 **Solusi:** 

1. Periksa file data mana yang hilang:

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

1. Jika file ditempatkan di direktori yang salah, ganti nama mereka di file kontrol:

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

1. Untuk mencegah hal ini, selalu verifikasi jalur file data sumber dengan `SELECT con_id, name FROM v$datafile ORDER BY con_id;` sebelum mengonfigurasi file parameter.

### Layanan PDB tidak mendaftar dengan pendengar (hanya multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdb-services-not-registering"></a>

**Penyebab:** Pendengar tidak mengetahui layanan PDB setelah membuka PDB.

 **Solusi:** 

1. Registrasi layanan paksa:

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

1. Jika layanan masih tidak muncul, periksa `local_listener` parameternya:

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

   Pastikan itu menunjuk ke alamat pendengar yang benar. Jika perlu, perbarui:

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

1. Verifikasi dengan:

   ```
   lsnrctl services
   ```

### PDB tidak dibuka secara otomatis setelah CDB restart (hanya multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdbs-not-opening-after-cdb-restart"></a>

**Penyebab:** Status penyimpanan PDB tidak dikonfigurasi.

 **Solusi:** 

Verifikasi bahwa status penyimpanan PDB telah dikonfigurasi:

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

Jika tidak ada baris yang dikembalikan, simpan status:

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

### Transportasi pengulangan Data Guard tidak berfungsi
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-odg-redo-transport-failure"></a>

**Penyebab:** Masalah konektivitas jaringan, konfigurasi TNS salah, atau parameter FAL tidak disetel.

 **Solusi:** 

1. Verifikasi siaga dalam mode MOUNT:

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

1. Periksa fal\_server dan fal\_client diatur dengan benar pada siaga:

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

1. Verifikasi konektivitas jaringan:

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

1. Periksa parameter log\_archive\_dest\_2 pada poin utama ke siaga (jika dikonfigurasi secara manual tanpa broker).

 **Data Guard menerapkan peningkatan lag dengan beberapa PDB (hanya multitenant)** 

**Penyebab:** Untuk CDB dengan beberapa PDB, redo apply bisa lebih lambat karena volume perubahan di semua container.

 **Solusi:** 

1. Periksa tarif penerapan:

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

1. Pertimbangkan untuk meningkatkan paralelisme untuk pengulangan berlaku (memerlukan lisensi 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;
   ```

1. Verifikasi tidak ada kendala sumber daya (CPU, I/O) pada instance siaga.

 **Pencadangan log arsip RMAN gagal ORA-19625** 

**Penyebab:** Otomatisasi khusus RDS telah membersihkan log arsip yang lebih lama dari disk, tetapi file kontrol RMAN masih memiliki catatannya.

 **Solusi:** 

1. Periksa silang dan bersihkan entri log arsip basi:

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

1. Re-run hanya cadangan log arsip:

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

### Penurunan pengguna umum gagal dalam multitenant (hanya multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-multitenant-user-drop-fails"></a>

 

**Penyebab:** Pengguna umum (diawali dengan C\#\#) harus dijatuhkan dengan klausa. `CONTAINER=ALL`

 **Solusi:** 

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

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

Verifikasi bahwa Anda terhubung ke`CDB$ROOT`:

```
SQL> SHOW CON_NAME;
```

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

Setelah migrasi berhasil, selesaikan tugas-tugas tambahan ini untuk memastikan database Oracle yang dikelola sendiri di EC2 siap produksi.

 **Perbarui string koneksi aplikasi** 

**Untuk Non-CDB:**
+ Arahkan aplikasi Anda ke titik akhir instans EC2 yang baru
+ Perbarui string koneksi untuk menggunakan IP instans EC2 atau nama host
+ Uji semua fungsionalitas aplikasi secara menyeluruh

**Untuk Multitenant:**
+ Arahkan aplikasi Anda ke nama layanan PDB instans EC2 baru (misalnya, ORCLDB atau nama PDB spesifik Anda)
+ Pastikan aplikasi terhubung ke PDB yang benar, bukan CDB
+ Perbarui string koneksi untuk menggunakan nama layanan PDB
+ Uji semua fungsionalitas aplikasi untuk setiap PDB

Contoh string koneksi:

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

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

 **Konfigurasikan strategi pencadangan** 

Siapkan strategi pencadangan komprehensif untuk database yang dikelola sendiri:

**Cadangan RMAN:**
+ Konfigurasikan skrip cadangan RMAN otomatis untuk pencadangan log penuh, inkremental, dan arsip
+ Siapkan kebijakan retensi cadangan berdasarkan sasaran titik pemulihan (RPO) Anda
+ Simpan cadangan di Amazon S3 untuk daya tahan dan efektivitas biaya
+ Secara teratur menguji prosedur restorasi cadangan

**AWS Backup:**
+ Gunakan [AWS Backup](https://aws.amazon.com/backup/)untuk snapshot volume EBS
+ Konfigurasikan jadwal pencadangan dan kebijakan penyimpanan
+ Aktifkan salinan cadangan lintas wilayah untuk pemulihan bencana

**Untuk Multitenant:**
+ Cadangan RMAN CDB secara otomatis mencakup semua PDB
+ Anda juga dapat mencadangkan PDB individu jika diperlukan
+ Pertimbangkan jadwal PDB-specific cadangan berdasarkan persyaratan bisnis

Contoh skrip cadangan RMAN:

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

 **Mengatur pemantauan** 

Menerapkan pemantauan komprehensif untuk database EC2-hosted Oracle Anda:

**Amazon CloudWatch**
+ Siapkan CloudWatch metrik untuk kesehatan instans EC2, penggunaan disk, dan metrik Oracle kustom
+ Buat CloudWatch alarm untuk ambang batas kritis
+ Gunakan CloudWatch Log untuk pemantauan log peringatan basis data

**Manajer Perusahaan Oracle (OEM):**
+ Jika tersedia, konfigurasikan OEM untuk pemantauan basis data
+ Mengatur pemantauan dan diagnostik kinerja
+ Konfigurasikan peringatan otomatis untuk peristiwa penting

**Third-party alat:**
+ Pertimbangkan alat seperti Datadog, New Relic, atau Prometheus untuk pemantauan database
+ Integrasikan dengan infrastruktur pemantauan yang ada

**Metrik utama untuk dipantau:**
+ Penggunaan tablespace
+ Ruang log arsip
+ Objek tidak valid
+ Jumlah sesi
+ Peristiwa tunggu
+ Pemanfaatan CPU dan memori
+ I/O kinerja

**Untuk Multitenant:**
+ Pantau keduanya CDB-level dan PDB-level metrik
+ Menyiapkan peringatan untuk penggunaan dan kuota sumber daya PDB
+ Lacak metrik PDB-specific kinerja

 **Konfigurasikan grup keamanan dan ACL jaringan** 

Tinjau dan kencangkan keamanan untuk instans EC2:

**Grup keamanan:**
+ Batasi akses port database hanya ke server aplikasi resmi dan host bastion
+ Hapus aturan yang terlalu permisif yang dibuat selama migrasi
+ Dokumentasikan aturan grup keamanan dan tujuannya

**ACL jaringan:**
+ Konfigurasikan ACL jaringan VPC untuk lapisan keamanan tambahan
+ Menerapkan strategi keamanan pertahanan mendalam

**Akses SSH:**
+ Batasi akses SSH ke rentang IP tertentu atau gunakan AWS Systems Manager Session Manager
+ Nonaktifkan otentikasi kata sandi dan gunakan otentikasi berbasis kunci saja
+ Menerapkan otentikasi multi-faktor (MFA) untuk akses istimewa

**Enkripsi:**
+ Aktifkan enkripsi saat istirahat untuk volume EBS
+ Aktifkan enkripsi dalam perjalanan untuk koneksi database menggunakan Oracle Native Network Encryption atau TLS
+ Putar kunci enkripsi secara teratur

**Menerapkan ketersediaan tinggi**

Jika beban kerja Anda membutuhkan ketersediaan tinggi, pertimbangkan untuk menerapkan:

**Penjaga Data Oracle:**
+ Konfigurasikan database siaga baru pada instans EC2 lain untuk pemulihan bencana
+ Untuk multitenant, Data Guard melindungi seluruh CDB termasuk semua PDB
+ Siaga dapat berada di Availability Zone atau Region yang berbeda
+ Menerapkan mekanisme failover otomatis menggunakan skrip atau alat pihak ketiga

**AWS Multi-AZ penyebaran:**
+ Terapkan instance siaga di Availability Zone yang berbeda
+ Gunakan Amazon Route 53 untuk failover DNS
+ Terapkan penyatuan koneksi tingkat aplikasi dengan dukungan failover

**Backup dan pemulihan:**
+ Pertahankan pencadangan rutin dengan prosedur pemulihan yang diuji
+ Tujuan waktu pemulihan dokumen (RTO) dan tujuan titik pemulihan (RPO)
+ Lakukan latihan pemulihan bencana secara teratur

**Lakukan pengujian aplikasi menyeluruh**

Sebelum menonaktifkan instance Kustom RDS:

**Pengujian fungsional:**
+ Verifikasi semua fitur aplikasi berfungsi dengan benar
+ Uji semua fungsionalitas yang bergantung pada database
+ Validasi integritas dan konsistensi data

**Pengujian kinerja:**
+ Bandingkan metrik kinerja dengan baseline RDS Custom
+ Identifikasi dan atasi regresi kinerja apa pun
+ Optimalkan kueri dan indeks sesuai kebutuhan

**Pengujian beban:**
+ Uji database di bawah beban puncak yang diharapkan
+ Verifikasi pemanfaatan sumber daya tetap dalam batas yang dapat diterima
+ Identifikasi dan atasi setiap kemacetan

**Pengujian failover (jika HA dikonfigurasi):**
+ Uji skenario failover
+ Verifikasi logika koneksi ulang aplikasi
+ Ukur RTO dan RPO aktual

**Backup dan restore testing:**
+ Verifikasi prosedur pencadangan dan pemulihan berfungsi dengan benar
+ Uji pemulihan titik-dalam-waktu
+ Validasi integritas cadangan

**Untuk Multitenant:**
+ Uji setiap PDB secara independen
+ Verifikasi isolasi PDB dan alokasi sumber daya
+  PDB-specific Operasi uji (klon, unplug/plug, dll.)

**Penonaktifan contoh Kustom RDS**

Setelah periode validasi yang sukses (biasanya 1-2 minggu):

1. **Pencadangan akhir**: Ambil cadangan akhir dari instance RDS Custom untuk tujuan pengarsipan

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

1. **Dokumentasikan migrasi**: Perbarui runbook dan dokumentasi dengan konfigurasi EC2 baru

1. **Hapus instance Kustom RDS**: Gunakan AWS Konsol atau CLI untuk menghapus instance

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

1. **Bersihkan sumber daya**: Hapus snapshot terkait, grup parameter, dan grup opsi jika tidak lagi diperlukan

1. **Perbarui dokumentasi**: Pastikan semua dokumentasi operasional mencerminkan EC2-based arsitektur baru

## Perbandingan: Duplikasi Aktif RMAN vs Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-RMAN-vs-ODG"></a>

Tabel berikut merangkum perbedaan utama antara dua opsi migrasi:


|  **Aspek**  |  **Duplikasi Aktif RMAN**  |  **Penjaga Data Oracle**  | 
| --- | --- | --- | 
| **Ketersediaan basis data sumber** | Online selama seluruh duplikasi | Online selama seluruh proses | 
| **Waktu henti** | Menit (hanya potongan akhir) | Detik ke menit (peralihan) | 
| **Kompleksitas** | Lebih rendah | Lebih tinggi | 
| **Durasi migrasi** | Operasi duplikasi tunggal | Pengaturan awal\+sinkronisasi berkelanjutan | 
| **Sinkronisasi berkelanjutan** | Tidak | Ya | 
| **Kemampuan mundur** | Manual (menjaga sumber tetap berjalan) | Built-in (otomatis) | 
| **Pengujian sebelum cutover** | Terbatas (tes setelah duplikasi) | Pengujian penuh mungkin (siaga dapat diuji) | 
| **Bandwidth jaringan** | Tinggi selama duplikasi | Sedang (terus menerus) | 
| **Dampak basis data sumber** | Minimal (baca operasi) | Minimal (ulang pengiriman) | 
| **Terbaik untuk** | Sebagian besar migrasi, pemotongan langsung | Mission-critical, diperlukan downtime mendekati nol | 
| **Non-CDB dukungan** | Ya | Ya | 
| **Dukungan multitenant** | Ya (seluruh CDB) | Ya (seluruh CDB) | 
| **Post-migration Negara PDB** | CDB terbuka, PDB DIPASANG | CDB terbuka, PDB DIPASANG | 
| **Membutuhkan RMAN** | Ya | Ya (untuk pencadangan awal dalam pendekatan berbasis cadangan) | 
| **Membutuhkan Data Guard** | Tidak | Ya | 
| **Tingkat keterampilan yang dibutuhkan** | Menengah | Lanjutan | 
| **Proses cutover** | Mengarahkan aplikasi ke EC2 | Perintah switchover\+aplikasi pengalihan | 

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

 

Tabel berikut merangkum perbedaan utama antara migrasi database non-CDB dan multitenant:


|  **Aspek**  |  **Non-CDB migrasi**  |  **Migrasi multitenant (CDB dengan PDB)**  | 
| --- | --- | --- | 
| **Jenis basis data** | Single-instance Non-CDB (mis.,) ORCL | CDB (sumber:RDSCDB, target:ORCL) CDB$ROOT PDB$SEED dengan\+\+satu atau lebih PDB | 
| **Ruang lingkup migrasi** | Database tunggal | Seluruh CDB (semua PDB disertakan secara otomatis) | 
| **Lingkup duplikasi RMAN** | Duplikat database tunggal | Duplikat seluruh CDB (semua kontainer) | 
| **Ruang lingkup Penjaga Data** | Melindungi database tunggal | Melindungi seluruh CDB (semua PDB disertakan secara otomatis) | 
| **File parameter** | Parameter init standar | Harus termasuk enable\_pluggable\_database = TRUE | 
| **Post-migration status basis data** | Database terbuka dalam mode BACA TULIS | CDB terbuka dalam READ WRITE mode; PDB tetap dalam keadaan MOUNTED | 
| **Pembukaan PDB** | N/A | Harus secara manual membuka semua PDB dengan ALTER PLUGGABLE DATABASE ALL OPEN | 
| **PDB buka otomatis saat startup** | N/A | Harus mengonfigurasi status penyimpanan PDB atau pemicu startup | 
| **Validasi** | Pemeriksaan database tunggal | Harus memvalidasi CDB dan setiap PDB secara individual | 
| **RDS-specific pembersihan** | Jatuhkan users/objects dari database tunggal | Jatuhkan pengguna umum dari CDB$ROOT (kaskade ke PDB); tangani pengguna C \#\# | 
| **TNS/Listener konfigurasi** | Layanan tunggal untuk database | Layanan CDB\+layanan PDB individu terdaftar secara dinamis | 
| **String koneksi aplikasi** | Connect ke database tunggal | Connect ke layanan PDB individual (bukan CDB) | 
| **Strategi Backup** | Backup database tunggal | Backup seluruh CDB (termasuk semua PDB) atau PDB individu | 
| **Manajemen sumber daya** | Database-level manajemen sumber daya | CDB-level dan manajemen PDB-level sumber daya dengan Resource Manager | 
| **Kompleksitas** | Kompleksitas yang lebih rendah | Kompleksitas yang lebih tinggi karena beberapa kontainer dan jalur OMF | 

## Praktik terbaik dan rekomendasi
<a name="RDS-Custom-for-Oracle-end-of-support-best-practices"></a>

Bagian ini memberikan praktik terbaik yang komprehensif untuk migrasi yang berhasil dari RDS Custom untuk Oracle ke EC2.

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

1. Lakukan penilaian menyeluruh:

   Sebelum memulai migrasi, lakukan penilaian komprehensif terhadap lingkungan Anda:
   + **Inventaris database**: Dokumentasikan semua database, ukurannya, arsitekturnya (non-CDB vs multitenant), dan dependensi
   + **Dependensi aplikasi**: Identifikasi semua aplikasi yang terhubung ke database dan metode koneksinya
   + **Garis dasar kinerja**: Tangkap metrik kinerja (CPU, memori, I/O, jaringan) untuk perbandingan pasca-migrasi
   + **Persyaratan Backup dan Pemulihan**: Dokumen RPO (Recovery Point Objective) dan RTO (Recovery Time Objective)
   + **Persyaratan kepatuhan**: Identifikasi persyaratan peraturan atau kepatuhan apa pun yang dapat memengaruhi migrasi

1. Pilih jenis instans EC2 yang tepat:

   Pilih jenis instans EC2 berdasarkan karakteristik beban kerja Anda:    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/RDS-Custom-for-Oracle-end-of-support.html)

    **Pedoman ukuran instans:** 
   + Mulailah dengan kelas instance yang sama dengan instans Kustom RDS Anda
   + Memantau pemanfaatan sumber daya selama migrasi pengujian
   + Pertimbangkan untuk menggunakan AWS Compute Optimizer untuk rekomendasi
   + Rencanakan ruang kepala 20-30% untuk pertumbuhan dan beban puncak

1. Desain arsitektur penyimpanan Anda:

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

   **Rekomendasi tata letak penyimpanan:**

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

    **Manfaat volume terpisah:** 
   + Alokasi IOPS independen
   + Manajemen kapasitas yang lebih mudah
   + Strategi pencadangan dan snapshot yang disederhanakan
   + Isolasi kinerja yang lebih baik

1.  Buat rencana rollback:

   Selalu memiliki strategi rollback:
   + **Biarkan instance RDS Custom tetap berjalan** selama periode validasi (disarankan 1-2 minggu)
   + **Pertahankan backup reguler** dari sumber dan target
   + **Prosedur rollback dokumen termasuk perubahan** string koneksi
   + **Uji proses rollback di lingkungan** non-produksi
   + **Tentukan kriteria rollback** (penurunan kinerja, inkonsistensi data, kesalahan aplikasi)

### Praktik terbaik eksekusi migrasi
<a name="RDS-Custom-for-Oracle-end-of-support-migration-best-practices"></a>

1. **Pengaturan waktu migrasi Anda:**

   Pilih jendela waktu yang optimal:
   + **Low-traffic periode**: Akhir pekan, hari libur, atau jam di luar sibuk
   + **Jendela pemeliharaan**: Sejajarkan dengan pemeliharaan terjadwal jika memungkinkan
   + **Hindari end/quarter akhir bulan**: Periode ini biasanya memiliki volume transaksi yang tinggi
   + **Pertimbangkan zona waktu**: Untuk aplikasi global, pilih waktu yang meminimalkan dampak di seluruh wilayah

1. **Rencana komunikasi:**

   Membangun komunikasi yang jelas:
   + **Pemberitahuan pemangku kepentingan**: Informasikan kepada semua pemangku kepentingan minimal 2 minggu sebelumnya
   + **Tim aplikasi**: Berkoordinasi dengan tim aplikasi untuk pembaruan string koneksi
   + **Pembaruan status**: Berikan pembaruan rutin selama migrasi
   + **Jalur eskalasi**: Tentukan prosedur eskalasi yang jelas untuk masalah
   + **Post-migration komunikasi**: Konfirmasikan penyelesaian yang berhasil dan tindakan tindak lanjut apa pun

1. **Pos pemeriksaan validasi:**

   Menerapkan validasi pada setiap tahap:

    **Pre-migration validasi:** 

   ```
   -- 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 validasi:** 

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

1. **Validasi kinerja:**

   Bandingkan metrik kinerja sebelum dan sesudah migrasi:

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

   Metrik utama untuk membandingkan:
   + Sesi aktif rata-rata
   + Waktu DB per transaksi
   + Pembacaan fisik per detik
   + Bacaan logis per detik
   + Ulangi ukuran per detik
   + Panggilan pengguna per detik
   + Mengurai waktu per eksekusi

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

1. Setelah migrasi, optimalkan kinerja database:

   1. **Penyetelan kinerja basis data:**

       **Kumpulkan statistik:** 

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

      **Optimalkan parameter memori:**

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

      **Konfigurasikan cache hasil:**

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

   1. Optimalisasi penyimpanan:

      **Aktifkan kompresi:**

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

      **Menerapkan partisi:**

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

   1. Menerapkan pemantauan dan peringatan:

      **CloudWatch metrik kustom:**

      Buat skrip untuk mempublikasikan metrik Oracle ke: 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.)
      ```

      **Mengatur CloudWatch alarm:**

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

   1. Pengerasan keamanan:

      **Keamanan basis data:**

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

      **Keamanan jaringan:**

      ```
      # 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. Strategi Backup dan Recovery:

   **Menerapkan strategi pencadangan yang komprehensif:**

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

   **Jadwalkan pencadangan dengan 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
   ```

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

 **1. Right-sizing**: 

Setelah migrasi, pantau dan optimalkan biaya:
+ **Gunakan AWS Cost Explorer** untuk menganalisis biaya EC2 dan EBS
+ **Aktifkan AWS Compute** Optimizer untuk rekomendasi tipe misalnya
+ **Tinjau CloudWatch metrik** untuk mengidentifikasi sumber daya yang kurang dimanfaatkan
+ **Pertimbangkan Instans Cadangan atau Savings Plans** untuk beban kerja yang dapat diprediksi

 **2. Optimalisasi penyimpanan:** 
+ **Menerapkan kebijakan siklus hidup** untuk cadangan S3 (pindah ke Glacier setelah 30 hari)
+ **Hapus snapshot EBS yang tidak digunakan** secara teratur
+ **Gunakan gp3 alih-alih gp2 untuk penghematan** biaya dengan kinerja yang sama
+ **Lepaskan dan hapus volume cadangan** setelah migrasi selesai

 **3. Otomasi:** 
+ **Otomatiskan start/stop** database non-produksi selama jam kerja
+ **Gunakan AWS Systems Manager** untuk manajemen patch
+ **Terapkan auto-scaling** untuk replika baca jika menggunakan Data Guard

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

Panduan preskriptif ini memberikan strategi migrasi terperinci untuk memindahkan database Oracle Anda dari Amazon RDS Custom for Oracle ke database Oracle yang dikelola sendiri di Amazon EC2. Dengan penghentian layanan RDS Custom for Oracle efektif 31 Maret 2027, penting untuk merencanakan dan menjalankan migrasi Anda jauh sebelumnya.

 **Takeaways kunci** 

 **Opsi migrasi:** 
+ **Duplikasi Aktif RMAN**: Terbaik untuk sebagian besar migrasi, membuat database sumber tetap online selama duplikasi, hanya memerlukan jendela cutover singkat untuk pengalihan aplikasi
+ **Oracle Data Guard**: Terbaik untuk beban kerja kritis misi yang membutuhkan waktu henti mendekati nol, menyediakan sinkronisasi berkelanjutan dan kemampuan peralihan bawaan

 **Dukungan arsitektur:** 
+ Kedua opsi migrasi mendukung arsitektur non-CDB (contoh tunggal tradisional) dan multitenant (CDB dengan PDB)
+ Untuk multitenant, kedua metode secara otomatis menangani seluruh CDB termasuk semua PDB dalam satu operasi
+ PDB memerlukan pembukaan manual dan konfigurasi buka otomatis pasca-migrasi

 **Faktor keberhasilan kritis:** 
+ Konfigurasi jaringan yang tepat dan konektivitas antara sumber dan target
+ Kompatibilitas versi yang tepat (versi utama, versi minor, Pembaruan Rilis, dan tambalan satu kali)
+ Bandwidth jaringan yang memadai untuk transfer data (RMAN) atau redo shipping (Data Guard)
+ Memahami bahwa duplikasi aktif RMAN membuat sumber tetap online - hanya diperlukan pemotongan singkat
+ Pengujian dan validasi menyeluruh sebelum menonaktifkan sumber
+ Tugas pasca-migrasi yang komprehensif termasuk cadangan, pemantauan, dan konfigurasi keamanan

 **Langkah selanjutnya:** 

1. Menilai arsitektur database Anda (non-CDB atau multitenant)

1. Pilih opsi migrasi yang sesuai berdasarkan toleransi waktu henti dan persyaratan kompleksitas Anda

1. Selesaikan semua langkah prasyarat termasuk pengaturan instans EC2 dan konfigurasi jaringan

1. Ikuti langkah-langkah migrasi terperinci untuk opsi yang Anda pilih

1. Lakukan validasi dan pengujian menyeluruh

1. Selesaikan tugas pasca-migrasi untuk memastikan kesiapan produksi

1. Menonaktifkan instance RDS Custom setelah validasi berhasil

 **Sumber daya tambahan** 
+ [Amazon RDS Custom untuk Panduan Pengguna Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom.html)
+ [Dokumentasi Database Oracle](https://docs.oracle.com/en/database/)
+ [Dokumentasi Oracle RMAN](https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/)
+ [Dokumentasi Penjaga Data Oracle](https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/)
+ [AWS Layanan Migrasi Database](https://aws.amazon.com/dms/)
+ [AWS Bimbingan Preskriptif](https://aws.amazon.com/prescriptive-guidance/)

 **Support** 

Untuk bantuan terkait migrasi Anda:
+ Hubungi AWS Support melalui AWS Management Console
+ Konsultasikan dengan dukungan Oracle untuk pertanyaan khusus database

## **Informasi dokumen**
<a name="RDS-Custom-for-Oracle-end-of-support-document-information"></a>

**Terakhir dimutakhirkan:** Maret 2026

**Kontributor:**
+ Sharath Chandra Kampili, Arsitek Solusi Spesialis Database, Amazon Web Services
+ Ibrahim Emara, Arsitek Solusi Spesialis Database, Amazon Web Services
+ Vetrivel Subramani, Arsitek Solusi Spesialis Database, Amazon Web Services