RDS Kustom untuk akhir dukungan Oracle

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.

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

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

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

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

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

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

5. Buat struktur direktori di EC2

   Struktur direktori tergantung pada arsitektur database Anda:

   contoh 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

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

6. Verifikasi konfigurasi basis data sumber

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

   contoh

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

2. Connect ke database dan periksa arsitektur:

   contoh

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

   contoh Untuk Non-CDB, output yang diharapkan

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

   contoh Untuk Multitenant (CDB), output yang diharapkan:

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

3. Jika Anda memiliki CDB multitenant, daftarkan semua PDB dan statusnya:

   contoh

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

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

   contoh

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

4. Periksa ukuran database total:

   contoh Untuk Non-CDB:

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

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

Garis waktu yang khas

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

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

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

Langkah-langkah instans (sumber) RDS Custom DB:

1. Jeda otomatisasi kustom Amazon RDS

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

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

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

5. Verifikasi database sumber berjalan dalam mode log arsip

6. Konfigurasikan tnsnames.ora di server DB Kustom RDS

Langkah-langkah instans EC2 DB (target):

1. Edit file parameter untuk EC2 (khusus arsitektur)

2. Konfigurasikan tnsnames.ora di EC2

3. Konfigurasikan lingkungan untuk instans EC2

4. Konfigurasikan Oracle Listener di EC2

5. Mulai database pada EC2 dalam status NOMOUNT

Langkah-langkah duplikasi RMAN:

1. Lakukan duplikasi aktif RMAN

2. Buka database (dan PDB untuk multitenant)

3. Konfigurasikan PDB auto-open (hanya multitenant)

4. Hapus pengguna dan objek khusus RDS Kustom

5. Buat SPFILE dan konfigurasikan startup otomatis

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

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

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

3. Hapus parameter RDS Custom-specific

   • dg_broker_config_file1dan dg_broker_config_file2 (jika ada - menunjukkan ada replika)

   • standby_file_management(jika ada)

   • spfile(kami akan membuat SPFILE baru nanti)

   • log_archive_destParameter apa pun yang menunjuk ke tujuan siaga (simpan hanya log_archive_dest_1 untuk pengarsipan lokal)

4. Tambahkan parameter konversi nama file (lihat di bawah)

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

Proses duplikasi aktif RMAN mencakup beberapa fase:

1. Menghubungkan ke basis data sumber dan target

2. Membuat SPFILE dari memori pada target

3. Mengembalikan file kontrol ke target

4. Memasang basis data target

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

6. Memulihkan basis data target

7. Membuka database target dengan RESETLOGS

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

   contoh 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

2. Pantau operasi yang berjalan lama:

   contoh 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

3. Memantau saluran RMAN:

   contoh

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

4. Periksa log peringatan:

   contoh 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-langkah instans RDS Custom DB (utama):

1. Jeda otomatisasi kustom Amazon RDS

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

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

4. Buat file kata sandi

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

6. Buat file parameter dari database sumber

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

2. Salin file kata sandi ke instans EC2

3. Edit file parameter untuk EC2 (khusus arsitektur)

4. Buat file parameter server dari file parameter

5. Kembalikan file kontrol siaga dan database

Langkah-langkah konfigurasi Data Guard:

1. Konfigurasikan pendengar Oracle pada kedua instance

2. Konfigurasikan tnsnames.ora pada kedua instance

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

4. Aktifkan konfigurasi Oracle Data Guard

5. Konfigurasikan fal_server dan fal_client pada instance siaga EC2

6. Konfigurasikan file log redo siaga pada kedua instance

7. Pulihkan contoh siaga

8. Lakukan peralihan manual

9. Buka database (dan PDB untuk multitenant)

10. Konfigurasikan PDB auto-open (hanya multitenant)

11. Hapus pengguna dan objek khusus RDS Kustom

12. Buat SPFILE dan konfigurasikan startup otomatis

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

2. Ubah db_unique_name: Dari (atau) menjadi ORCL_A RDSCDB_A ORCL_B

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

4. Hapus parameter RDS Custom-specific

   • dg_broker_config_file1dan dg_broker_config_file2 (jika ada)

   • standby_file_management(jika ada)

   • spfile(kami akan membuat yang baru SPFILE nanti)

   • log_archive_destParameter apa pun yang menunjuk ke tujuan siaga

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

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

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

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

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

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

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

1. Periksa versi zona waktu:

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

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

3. Coba lagi drop:

   sqlplus / as sysdba
   SQL> DROP USER RDSADMIN CASCADE;

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;

2. Verifikasi level patch $ORACLE_HOME:

   # On both instances
   $ORACLE_HOME/OPatch/opatch lsinventory

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

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

   cd $ORACLE_HOME/OPatch
   ./datapatch -verbose

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

1. Verifikasi grup keamanan mengizinkan port dua arah

2. Periksa iptables di EC2:

   sudo iptables -L INPUT -n -v

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

4. Uji konektivitas:

   telnet <EC2_instance_IP> 1521
   tnsping DB_SOURCE
   tnsping DB_TARGET

1. Periksa file data mana yang hilang:

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

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

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

1. Registrasi layanan paksa:

   SQL> ALTER SYSTEM REGISTER;

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

3. Verifikasi dengan:

   lsnrctl services

1. Verifikasi siaga dalam mode MOUNT:

   SQL> SELECT status FROM v$instance;

2. Periksa fal_server dan fal_client diatur dengan benar pada siaga:

   SQL> SHOW PARAMETER fal_server
   SQL> SHOW PARAMETER fal_client

3. Verifikasi konektivitas jaringan:

   tnsping ORCL_A # or RDSCDB_A for multitenant

4. Periksa parameter log_archive_dest_2 pada poin utama ke siaga (jika dikonfigurasi secara manual tanpa broker).

1. Periksa tarif penerapan:

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

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

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

1. Periksa silang dan bersihkan entri log arsip basi:

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

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

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

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

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

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

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

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

2. Pilih jenis instans EC2 yang tepat:

   Pilih jenis instans EC2 berdasarkan karakteristik beban kerja Anda:

   Jenis Beban Kerja	Keluarga Instance yang Direkomendasikan	Karakteristik Utama
   OLTP tujuan umum	M6i, M6a, M7i	Komputasi, memori, dan jaringan yang seimbang
   Memory-intensive	R6i, R6a, R7i, X2idn	Rasio Memori-ke-CPU yang tinggi
   Compute-intensive	C6i, C6a, C7i	Kinerja CPU tinggi
   I/O-intensive	i4i, iM4GN	Penyimpanan SSD NVMe lokal yang tinggi
   Beban kerja campuran	M5, M5a, M5n	Cost-effective kinerja seimbang

   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

3. Desain arsitektur penyimpanan Anda:

   Jenis volume EBS:

   Jenis Volume	Kasus Penggunaan	Performa	Biaya
   gp3	Tujuan umum, sebagian besar beban kerja	Hingga 16.000 IOPS, 1.000 MB/s	Rendah
   io2 Blok Ekspres	Mission-critical, kinerja tinggi	Hingga 256.000 IOPS, 4.000 MB/s	Tinggi
   Io1	High-performance database	Hingga 64.000 IOPS, 1.000 MB/s	Medium-High
   gp2	Tujuan umum warisan	Hingga 16.000 IOPS	Rendah

   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

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

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

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

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

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

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;

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

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

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

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

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

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

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

5. Lakukan validasi dan pengujian menyeluruh

6. Selesaikan tugas pasca-migrasi untuk memastikan kesiapan produksi

7. Menonaktifkan instance RDS Custom setelah validasi berhasil