Fine del supporto per RDS Custom for Oracle

1. Avvia e configura l'istanza EC2

   Avvia un'istanza EC2 tenendo conto delle seguenti considerazioni:

   • Tipo di istanza: scegli un tipo di istanza EC2 che soddisfi i requisiti di risorse del tuo carico di lavoro. Utilizzare la stessa classe di istanza dell'istanza RDS Custom è un buon punto di partenza. Considerate i requisiti di memoria, CPU e larghezza di banda di rete.

   • Sistema operativo: Oracle Linux o Red Hat Enterprise Linux (corrispondente o compatibile con la versione del sistema operativo RDS Custom in uso)

   • Software Oracle: installa il software Oracle Database (stessa versione principale, versione secondaria, Release Update e idealmente le stesse patch singole di RDS Custom). Assicurati che il software Oracle sia installato in/u01/app/oracle/ o nella tua posizione preferita.

   • Storage: configura i volumi Amazon EBS con dimensioni e IOPS appropriati per soddisfare i requisiti del carico di lavoro. Prendi in considerazione l'utilizzo di volumi gp3 per prestazioni convenienti o io2 Block Express per carichi di lavoro ad alte prestazioni.

2. Configura l'architettura di storage

   1. Storage del file system (consigliato per la maggior parte degli scenari)

      • Utilizza directory di file system standard per i file di dati Oracle

      • Più semplice da gestire e adatto alla maggior parte dei carichi di lavoro

      • Questa guida utilizza esempi di storage dei file system

   2. Oracle Automatic Storage Management (ASM)

      • Se il tuo carico di lavoro richiede ASM, installa e configura ASM autonomo sull'istanza EC2

      • Modifica di conseguenza tutti i parametri del percorso nel file init per utilizzare i gruppi di dischi ASM (ad esempio, +DATA, +FRA)

      • Il processo di migrazione è simile per ASM, con regolazioni del percorso

3. Imposta il meccanismo di trasferimento dei file

   Crea un meccanismo per trasferire file tra istanze RDS Custom ed EC2. A questo scopo, sono disponibili numerose opzioni:

   1. Opzione A: Amazon S3 (consigliato per la maggior parte degli scenari)

      • Crea un bucket Amazon S3 o usane uno esistente

      • Installa e configura la AWS CLI su entrambe le istanze

      • Per istruzioni, consulta Guida introduttiva a. AWS CLI

   2. Opzione B: Diretta SCP/SFTP

      • Se le porte SSH sono aperte tra le istanze, puoi trasferire direttamente i file

      • Adatto per file di piccole dimensioni come file di parametri e file di password

   3. Opzione C: Amazon EFS

      • Se hai già installato Amazon EFS su entrambe le istanze, puoi utilizzarlo come file system condiviso.

      • Adatto per ambienti con infrastruttura EFS esistente

      Questa guida utilizza Amazon S3 per esempi, ma puoi adattare i comandi al metodo scelto.

4. Configura la connettività di rete

   Garantisci la connettività di rete tra le istanze RDS Custom ed EC2:

   • Stesso VPC: i gruppi di sicurezza devono consentire il traffico bidirezionale sulla porta del listener Oracle (impostazione predefinita 1521 o porta personalizzata)

   • VPC diversi (stesso account): configura il peering VPC e configura tabelle di routing e gruppi di sicurezza

   • Account diversi: configura il peering VPC tra account o utilizza Transit Gateway AWS

   • Verifica della connettività: utilizza ping e telnet per testare la connettività sulla porta del database

5. Crea una struttura di directory su EC2

   La struttura delle cartelle dipende dall'architettura del database:

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

   Esempio Per Multitenant (CDB con 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

   Nota

   RDS Custom for Oracle utilizza Oracle Managed Files (OMF) per i file di dati PDB con sottodirectory (ad es.). GUID-based /rdsdbdata/db/pdb/RDSCDB_A/{GUID}/datafile/ Il processo di migrazione creerà automaticamente la struttura di sottodirectory necessaria sulla destinazione. È sufficiente creare le directory principali.

   Strategia di storage: prendi in considerazione l'utilizzo di un volume EBS separato per/u01/app/oracle/backup per scollegarlo e rimuoverlo facilmente dopo il completamento della migrazione, liberando i costi di storage.

6. Verifica la configurazione del database di origine

1. Accedi all'host del database RDS Custom come utente rdsdb e imposta l'ambiente:

   Esempio

   # 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 al database e verifica l'architettura:

   Esempio

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

   Esempio Per Non-CDB, output previsto

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

   Esempio Per Multitenant (CDB), output previsto:

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

3. Se hai un CDB multitenant, elenca tutti i PDB e il loro stato:

   Esempio

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

   Output previsto (esempio con 1 PDB denominato ORCLDB):

   Esempio

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

4. Controlla la dimensione totale del database:

   Esempio Per Non-CDB:

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

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

Cronologia tipica

1. Fase di duplicazione (la fonte rimane online): da 30 minuti a diverse ore a seconda delle dimensioni del database

2. Fase di convalida (la fonte rimane online): da ore a giorni, in base alle esigenze

3. Fase di transizione (breve periodo di inattività): minuti per reindirizzare le applicazioni a EC2

Procedura dell'istanza DB personalizzata RDS (origine):

1. Metti in pausa l'automazione personalizzata di Amazon RDS

2. Verifica l'architettura del database (non CDB o CDB con PDB)

3. Crea un file di password e un file di parametri dal database di origine

4. Copia il file delle password e il file dei parametri nell'istanza EC2 di destinazione

5. Verifica che il database di origine sia in esecuzione in modalità registro di archiviazione

6. Configurare tnsnames.ora sul server RDS Custom DB

Fasi dell'istanza DB EC2 (destinazione):

1. Modifica il file dei parametri per EC2 (specifico dell'architettura)

2. Configura tnsnames.ora su EC2

3. Configura l'ambiente per l'istanza EC2

4. Configura Oracle Listener su EC2

5. Avvia il database su EC2 nello stato NOMOUNT

Fasi di duplicazione RMAN:

1. Eseguire la duplicazione attiva di RMAN

2. Apri il database (e i PDB per il multitenant)

3. Configura l'apertura automatica del PDB (solo multitenant)

4. Rimuovi utenti e oggetti specifici di RDS Custom

5. Crea SPFILE e configura l'avvio automatico

6. Riprendi l'automazione personalizzata di Amazon RDS all'origine (se la mantieni attiva)

1. Aggiorna il nome del database: per il multitenant, modifica tutte le occorrenze di RDSCDB in ORCL

2. Converti i percorsi personalizzati RDS in percorsi EC2: sostituisci /rdsdbdata/ con//oracle/ u01/app

3. Rimuovi Custom-specific i parametri RDS

   • dg_broker_config_file1e dg_broker_config_file2 (se presente, indica l'esistenza di una replica)

   • standby_file_management(se presente)

   • spfile(creeremo un nuovo SPFILE più avanti)

   • Qualsiasi log_archive_dest parametro che punti a destinazioni in standby (conservare solo log_archive_dest_1 per l'archiviazione locale)

4. Aggiungi parametri di conversione dei nomi di file (vedi sotto)

5. Regola i parametri di memoria in base alla dimensione dell'istanza EC2 (opzionale ma consigliato)

Il processo di duplicazione attiva di RMAN include diverse fasi:

1. Connessione ai database di origine e di destinazione

2. Creazione di un file SPFILE dalla memoria sulla destinazione

3. Ripristino del file di controllo sulla destinazione

4. Montaggio del database di destinazione

5. Copia di tutti i file di dati dall'origine alla destinazione tramite la rete (l'origine rimane online)

6. Ripristino del database di destinazione

7. Apertura del database di destinazione con RESETLOGS

1. Monitora l'uscita RMAN:

   La sessione RMAN mostrerà informazioni dettagliate sullo stato di avanzamento, tra cui:

   • Allocazione dei canali

   • Avanzamento della copia dei file di dati

   • Tempo di completamento stimato

   • Byte elaborati

   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

   Esempio Output di esempio:

   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. Monitora le operazioni di lunga durata:

   Esempio In una sessione SQL*Plus separata sull'istanza EC2 di destinazione:

   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;

   Questa query mostra:

   • opname: nome dell'operazione (ad esempio, «RMAN: ripristino completo dei file di dati»)

   • sofar: Blocchi elaborati finora

   • totalwork: Blocchi totali da elaborare

   • pct_complete: Percentuale di completamento

   • time_remaining: secondi rimanenti stimati

   • elapsed_seconds: Tempo trascorso finora

3. Monitora i canali RMAN:

   Esempio

   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. Controlla il registro degli avvisi:

   Esempio Sull'istanza EC2 di destinazione, monitora il registro degli avvisi per eventuali errori o avvisi:

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

   Problemi comuni durante la duplicazione di RMAN:

   • Timeout di rete

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

     Soluzione: aumenta i valori di timeout di rete in entrambe le sqlnet.ora istanze:

     SQLNET.RECV_TIMEOUT=600
     SQLNET.SEND_TIMEOUT=600

   • Spazio insufficiente sull'obiettivo

     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

     Soluzione: controlla lo spazio disponibile e aggiungi ulteriore capacità di volume EBS:

     df -h /u01/app/oracle/oradata

   • Errori nel file dei parametri

     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

     Soluzione: verificate che tutte le directory nel file dei parametri esistano e dispongano delle autorizzazioni appropriate.

   • Mancata corrispondenza del file di password

     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

     Soluzione: assicuratevi che il file delle password sulla destinazione corrisponda all'origine e abbia il nome corretto (orapwORCL).

Fasi (principali) dell'istanza DB personalizzata RDS:

1. Metti in pausa l'automazione personalizzata di Amazon RDS

2. Verifica l'architettura del database (non CDB o CDB con PDB)

3. Verifica che il database principale sia in esecuzione in modalità di registro di archivio e sia abilitato FORCE_LOGGING

4. Crea un file di password

5. Esegui un backup online RMAN del database principale (o usa la duplicazione attiva)

6. Crea un file di parametri dal database di origine

7. Copia i set di backup, il file dei parametri e il file delle password nell'istanza EC2 di destinazione

Fasi dell'istanza DB EC2 (standby):

1. Copia tutti i file dall'origine all'istanza EC2

2. Copia il file delle password nell'istanza EC2

3. Modifica il file dei parametri per EC2 (specifico dell'architettura)

4. Crea il file dei parametri del server dal file dei parametri

5. Ripristina il file di controllo e il database in standby

Fasi di configurazione di Data Guard:

1. Configura i listener Oracle su entrambe le istanze

2. Configura tnsnames.ora su entrambe le istanze

3. Avvia il broker Oracle Data Guard su entrambe le istanze (facoltativo ma consigliato)

4. Abilita la configurazione di Oracle Data Guard

5. Configura fal_server e fal_client sull'istanza di standby EC2

6. Configura i redo log file in standby su entrambe le istanze

7. Ripristina l'istanza in standby

8. Esegui la commutazione manuale

9. Apri il database (e i PDB per il multitenant)

10. Configura l'apertura automatica del PDB (solo multitenant)

11. Rimuovi utenti e oggetti specifici di RDS Custom

12. Crea SPFILE e configura l'avvio automatico

1. Aggiorna il nome del database: per il multitenant, modifica tutte le occorrenze di in RDSCDB ORCL

2. Cambia db_unique_name: Da (o) a ORCL_A RDSCDB_A ORCL_B

3. Converti i percorsi personalizzati RDS in percorsi EC2: sostituisci con /rdsdbdata/ /u01/app/oracle/

4. Rimuovi i parametri RDS Custom-specific

   • dg_broker_config_file1e dg_broker_config_file2 (se presente)

   • standby_file_management(se presente)

   • spfile(ne creeremo una nuova SPFILE più tardi)

   • Qualsiasi log_archive_dest parametro che punti a destinazioni in standby

5. Regola i parametri di memoria in base alla dimensione dell'istanza EC2 (opzionale ma consigliato)

1. Monitora le statistiche di Data Guard:

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

   Metriche chiave da monitorare:

   • ritardo di trasporto: differenza di tempo tra il momento in cui il ripristino è stato generato sul sistema primario e quello in cui è stato ricevuto in standby

   • apply lag: differenza di tempo tra il momento in cui il ripristino è stato generato e l'applicazione in standby

   • apply rate: Frequenza con cui viene applicato il ripristino () MB/sec

   • ripristino ricevuto: ripristino totale ricevuto in modalità standby

   • ripristino applicato: ripristino totale applicato in modalità standby

2. Monitora la spedizione dei log di archivio:

   Sul primario (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';

   In standby (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. Monitora il processo di ripristino gestito:

   -- 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. Monitora la frequenza di ripetizione delle applicazioni per più tenant:

   Per i database multitenant, monitora la frequenza di applicazione 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. Monitora i registri di ripristino in standby:

   -- 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. Stima del completamento della sincronizzazione:

   Calcola il tempo rimanente in base alla tariffa di applicazione:

   -- 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. Controlla le versioni del fuso orario:

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

2. Come soluzione alternativa, imposta la variabile di ambiente del file del fuso orario in modo che corrisponda a quella disponibile in $ORACLE_HOME:

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

   Modifica il numero in modo che corrisponda alla versione disponibile nell'installazione.

3. Riprova il rilascio:

   sqlplus / as sysdba
   SQL> DROP USER RDSADMIN CASCADE;

1. Controlla l'esatta versione RU sia sull'origine che sulla destinazione:

   -- 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. Verifica il livello di patch $ORACLE_HOME:

   # On both instances
   $ORACLE_HOME/OPatch/opatch lsinventory

3. Se le versioni non corrispondono, allineale prima della migrazione applicando o ripristinando le patch secondo necessità.

4. Se devi procedere con RU non corrispondenti, esegui datapatch dopo la migrazione:

   cd $ORACLE_HOME/OPatch
   ./datapatch -verbose

5. Verifica la presenza di oggetti non validi e ricompila:

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

1. Verifica che i gruppi di sicurezza consentano la porta in modo bidirezionale

2. Controlla iptables su EC2:

   sudo iptables -L INPUT -n -v

3. Aggiungi una regola se necessario:

   # 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. Verifica la connettività:

   telnet <EC2_instance_IP> 1521
   tnsping DB_SOURCE
   tnsping DB_TARGET

1. Controlla quali file di dati mancano:

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

2. Se i file sono stati inseriti nella directory sbagliata, rinominali nel file di controllo:

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

3. Per evitare che ciò accada, verificate sempre i percorsi dei file di dati di origine con SELECT con_id, name FROM v$datafile ORDER BY con_id; prima di configurare il file dei parametri.

1. Registrazione forzata del servizio:

   SQL> ALTER SYSTEM REGISTER;

2. Se i servizi continuano a non essere visualizzati, controlla il local_listener parametro:

   SQL> SHOW PARAMETER local_listener;

   Assicurati che punti all'indirizzo corretto dell'ascoltatore. Se necessario, aggiornalo:

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

3. Verifica con:

   lsnrctl services

1. Verifica che lo standby sia in modalità MOUNT:

   SQL> SELECT status FROM v$instance;

2. Verifica che fal_server e fal_client siano impostati correttamente in standby:

   SQL> SHOW PARAMETER fal_server
   SQL> SHOW PARAMETER fal_client

3. Verifica la connettività di rete:

   tnsping ORCL_A # or RDSCDB_A for multitenant

4. Controlla il parametro log_archive_dest_2 sui punti principali di standby (se configurato manualmente senza broker).

1. Controlla la tariffa di applicazione:

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

2. Valuta la possibilità di aumentare il parallelismo per redo apply (richiede la licenza 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. Verifica che non vi siano vincoli di risorse (CPU I/O) sull'istanza di standby.

1. Esegui un controllo incrociato e ripulisci le voci obsolete del registro di archivio:

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

2. Re-run solo il backup del registro di archivio:

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

1. Backup finale: esegui un backup finale dell'istanza RDS Custom per scopi di archiviazione

   # 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. Documenta la migrazione: aggiorna i runbook e la documentazione con la nuova configurazione EC2

3. Eliminare l'istanza personalizzata RDS: utilizza la AWS console o la CLI per eliminare l'istanza

   # 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. Pulisci le risorse: rimuovi le istantanee, i gruppi di parametri e i gruppi di opzioni associati se non sono più necessari

5. Aggiorna la documentazione: assicurati che tutta la documentazione operativa rifletta la nuova architettura EC2-based

1. Effettuare una valutazione approfondita:

   Prima di iniziare la migrazione, esegui una valutazione completa del tuo ambiente:

   • Inventario dei database: documenta tutti i database, le loro dimensioni, le architetture (non CDB o multitenant) e le dipendenze

   • Dipendenze delle applicazioni: identifica tutte le applicazioni che si connettono al database e i relativi metodi di connessione

   • Linea di base delle prestazioni: acquisisci i parametri delle prestazioni (CPU I/O, memoria e rete) per confrontarli dopo la migrazione

   • Requisiti di backup e ripristino: Document RPO (Recovery Point Objective) e RTO (Recovery Time Objective)

   • Requisiti di conformità: Identifica eventuali requisiti normativi o di conformità che possono influire sulla migrazione

2. Scegli il tipo di istanza EC2 giusto:

   Seleziona un tipo di istanza EC2 in base alle caratteristiche del tuo carico di lavoro:

   Tipo di carico di lavoro	Famiglia di istanze consigliata	Caratteristiche principali
   OLTP per uso generico	M6i, M6a, M7i	Elaborazione, memoria e rete bilanciate
   Memory-intensive	R6i, R6a, R7i, X2idn	Elevato rapporto memoria/CPU
   Compute-intensive	C6i, C6a, C7i	Alte prestazioni della CPU
   I/O-intensive	I4i, Im4gn	Archiviazione SSD NVMe locale elevata
   Carichi di lavoro misti	M5, M5 A, 5 Mn	Cost-effective prestazioni equilibrate

   Linee guida per il dimensionamento delle istanze:

   • Inizia con la stessa classe di istanza dell'istanza RDS Custom

   • Monitora l'utilizzo delle risorse durante una migrazione di test

   • Prendi in considerazione l'utilizzo di AWS Compute Optimizer per i consigli

   • Pianifica un margine di crescita del 20-30% per la crescita e i picchi di carico

3. Progetta la tua architettura di storage:

   Tipi di volume EBS:

   Tipo di volume	Caso d'uso	Prestazioni	Costo
   gp3	Scopo generico, la maggior parte dei carichi di lavoro	Fino a 16.000 IOPS, 1.000 MB/s	Bassa
   io2 Block Express	Mission-critical, ad alte prestazioni	Fino a 256.000 IOPS, 4.000 MB/s	Elevata
   Io 1	High-performance banche dati	Fino a 64.000 IOPS, 1.000 MB/s	Medium-High
   gp2	Legacy per uso generico	Fino a 16.000 IOPS	Bassa

   Raccomandazioni sul layout di archiviazione:

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

   Vantaggi dei volumi separati:

   • Allocazione IOPS indipendente

   • Gestione della capacità più semplice

   • Strategie di backup e snapshot semplificate

   • Migliore isolamento delle prestazioni

4. Stabilisci un piano di rollback:

   Adotta sempre una strategia di rollback:

   • Mantieni attiva l'istanza RDS Custom durante il periodo di convalida (si consigliano 1-2 settimane)

   • Mantieni backup regolari sia dell'origine che della destinazione

   • Procedure di rollback dei documenti, comprese le modifiche alla stringa di connessione

   • Prova il processo di rollback in un ambiente non di produzione

   • Definisci i criteri di rollback (peggioramento delle prestazioni, incoerenza dei dati, errori delle applicazioni)

1. Tempistica della migrazione:

   Scegli la finestra temporale ottimale:

   • Low-traffic periodi: fine settimana, festivi o ore non di punta

   • Finestre di manutenzione: se possibile, allineatele alla manutenzione programmata

   • Evita la end/quarter fine del mese: questi periodi hanno in genere volumi di transazioni elevati

   • Prendi in considerazione i fusi orari: per le applicazioni globali, scegli un orario che riduca al minimo l'impatto tra le regioni

2. Piano di comunicazione:

   Stabilisci una comunicazione chiara:

   • Notifica alle parti interessate: informa tutte le parti interessate con almeno 2 settimane di anticipo

   • Team applicativi: coordinatevi con i team delle applicazioni per gli aggiornamenti delle stringhe di connessione

   • Aggiornamenti di stato: fornite aggiornamenti regolari durante la migrazione

   • Percorso di escalation: definisci procedure di escalation chiare per i problemi

   • Post-migration comunicazione: confermare il completamento con successo e le eventuali azioni successive

3. Punti di controllo di convalida:

   Implementare la convalida in ogni fase:

   Pre-migration validation:

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

   -- 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. Validazione delle prestazioni:

   Confronta le metriche delle prestazioni prima e dopo la migrazione:

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

   Metriche chiave da confrontare:

   • Media delle sessioni attive

   • Tempo DB per transazione

   • Letture fisiche al secondo

   • Letture logiche al secondo

   • Ripeti le dimensioni al secondo

   • Chiamate utente al secondo

   • Tempo di analisi per esecuzione

1. Dopo la migrazione, ottimizza le prestazioni del database:

   1. Ottimizzazione delle prestazioni del database:

      Raccogliere statistiche:

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

      Ottimizza i parametri di memoria:

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

      Configura la cache dei risultati:

      -- 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. Ottimizzazione dello spazio di archiviazione:

      Abilita la compressione:

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

      Implementa il partizionamento:

      -- 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. Implementare il monitoraggio e gli avvisi:

      CloudWatch metriche personalizzate:

      Crea uno script per pubblicare le metriche Oracle su: 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.)

      Imposta gli CloudWatch allarmi:

      # 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. Rafforzamento della sicurezza:

      Sicurezza del database:

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

      Sicurezza della rete:

      # 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. Strategia di backup e ripristino:

   Implementazione di una strategia di backup completa:

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

   Pianifica i backup con 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. Valuta l'architettura del tuo database (non CDB o multitenant)

2. Scegliete l'opzione di migrazione appropriata in base ai vostri requisiti di complessità e tolleranza ai tempi di inattività

3. Completa tutti i passaggi prerequisiti, tra cui la configurazione dell'istanza EC2 e la configurazione della rete

4. Segui i passaggi di migrazione dettagliati per l'opzione scelta

5. Esegui convalide e test approfonditi

6. Completa le attività successive alla migrazione per garantire la disponibilità della produzione

7. Disattiva l'istanza RDS Custom dopo la convalida riuscita