Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Fine del supporto per RDS Custom for Oracle
<a name="RDS-Custom-for-Oracle-end-of-support"></a>

**Nota**  
Avviso di fine del supporto: il 31 marzo 2027, AWS terminerà il supporto per Amazon RDS Custom for Oracle. Dopo il 31 marzo 2027, non sarà più possibile accedere alla console RDS Custom for Oracle o alle risorse RDS Custom for Oracle. Per ulteriori informazioni, consulta [Fine del supporto per RDS Custom for Oracle](#RDS-Custom-for-Oracle-end-of-support).

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

Dopo un'attenta valutazione, AWS ha deciso di interrompere il servizio Amazon RDS Custom for Oracle. **Il servizio diventerà obsoleto a partire dal 31 marzo 2027.** Questa guida prescrittiva fornisce strategie di migrazione dettagliate per aiutarti a migrare da RDS Custom for Oracle ai database Oracle autogestiti su Amazon Elastic Compute Cloud (Amazon EC2) Elastic Compute Cloud (Amazon EC2).

### Tempistiche chiave
<a name="RDS-Custom-for-Oracle-end-of-support-key_timelines"></a>
+ **Dal 31 marzo 2026 al 31 marzo 2027**: ti consigliamo di migrare da RDS Custom for Oracle all'esecuzione di Oracle su EC2. Durante questo periodo, puoi continuare a utilizzare RDS Custom for Oracle con le funzionalità e il supporto esistenti.
+ **Dopo il 31 marzo 2027**: non sarà più possibile utilizzare il servizio RDS Custom for Oracle.

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

Questa guida è destinata a:
+ Amministratori di database responsabili delle migrazioni dei database Oracle
+ Architetti del cloud che pianificano strategie di migrazione
+ DevOps ingegneri che gestiscono l'infrastruttura di database
+ Responsabili IT che supervisionano il processo di migrazione

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

Prima di iniziare, assicurati di disporre dei seguenti elementi:
+ Un'istanza Amazon RDS Custom for Oracle attiva che esegue Oracle 19c Enterprise Edition
+ Autorizzazioni IAM ( AWS Identity and Access Management) appropriate per creare e gestire istanze EC2
+ Comprensione dell'architettura del database (CDB non CDB o CDB multitenant con PDB)
+ Pianificazione della connettività di rete tra istanze di origine e di destinazione
+ Strategia di backup e ripristino per la migrazione

## Opzioni di migrazione
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options"></a>

Come parte del processo di migrazione, puoi scegliere una delle due opzioni di migrazione in base ai requisiti aziendali e al caso d'uso:

### Opzione 1: RMAN Active Duplication (migrazione) Online/Offline
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options-RMAN"></a>

**Ideale per**
+ Carichi di lavoro che possono permettersi tempi di inattività pianificati durante il montaggio finale
+ Requisiti di migrazione più semplici con un minor numero di parti mobili
+ Database per i quali si desidera una migrazione semplice e una tantum
+ Scenari in cui non è necessaria la sincronizzazione continua prima del cutover

**Caratteristiche chiave**
+ Tempo di **inattività: tempo** di inattività minimo durante il cutover finale (il database rimane online durante la duplicazione, breve tempo di inattività per il taglio finale)
+ **Complessità: minore complessità** con la duplicazione diretta del database
+ **Durata: il** tempo di migrazione dipende dalle dimensioni del database e dalla larghezza di banda della rete
+ **Fallback**: richiede la manutenzione del database di origine fino al completamento della convalida
+ **Funzionalità online**: il database di origine rimane online e accessibile durante il processo di duplicazione

**Approccio alla migrazione:** la duplicazione attiva RMAN crea una copia esatta del database di origine sulla destinazione copiando i file di database dalla rete dal database di origine attivo e in esecuzione. Il database di origine rimane online e accessibile alle applicazioni durante il processo di duplicazione. Per i database multi-tenant, RMAN duplica automaticamente l'intero CDB`CDB$ROOT`, compresi tutti i database collegabili`PDB$SEED`, in un'unica operazione. È necessaria solo una breve finestra di dialogo per reindirizzare le applicazioni alla nuova istanza EC2.

### Opzione 2: Oracle Data Guard (migrazione online)
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options-Oracle-Data-Guard"></a>

**Ideale per**
+ Carichi di lavoro di produzione che richiedono tempi di inattività minimi
+ Mission-critical database che devono rimanere disponibili
+ Scenari in cui è necessaria una sincronizzazione continua prima del cutover
+ Migrazioni che richiedono funzionalità di fallback integrate

**Caratteristiche chiave**
+ Tempo di **inattività: tempo** di Near-zero inattività (da secondi a minuti per il passaggio al digitale)
+ **Complessità: maggiore complessità** con la configurazione Data Guard
+ **Durata**: tempo di configurazione iniziale più sincronizzazione continua fino allo switchover
+ **Fallback**: funzionalità di Built-in fallback che consente di mantenere la sorgente in standby

**Approccio alla migrazione:** Oracle Data Guard mantiene un database di standby sincronizzato inviando e applicando continuamente i redo log dal database principale. Quando sei pronto per completare la migrazione, esegui un passaggio che promuove lo standby EC2 a quello primario con tempi di inattività minimi. Per i database multitenant, Data Guard protegge automaticamente l'intero CDB, inclusi tutti i PDB.

 **Matrice decisionale** 

Utilizzate la seguente matrice per scegliere l'opzione di migrazione appropriata:


|  **Aspetto**  |  **Duplicazione attiva RMAN**  |  **Oracle Data Guard**  | 
| --- | --- | --- | 
| **Disponibilità del database di origine** | Online durante la duplicazione | Online durante l'intero processo | 
| **Tempi di inattività accettabili** | Da minuti a ore (cutover finale) | Da secondi a minuti (commutazione) | 
| **Complessità della migrazione** | Più basso | Più alto | 
| **Sincronizzazione continua** | No | Sì | 
| **Capacità di fallback** | Manuale (mantieni il codice sorgente) | Built-in (automatico) | 
| **Test prima del taglio** | Limitato | Possibilità di test completi | 
| **Requisiti di larghezza di banda di rete** | Elevato durante la duplicazione | Moderato (continuo) | 
| **Ideale per** | La maggior parte delle migrazioni dev/test, interruzione pianificata | Produzione, mission critical, tempi di inattività quasi nulli | 

### Considerazioni sull'architettura
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options-architecture-considerations"></a>

Entrambe le opzioni di migrazione supportano due architetture di database Oracle:

 **Non-CDB** 

Database Oracle tradizionali a istanza singola senza architettura multitenant. Questi database:
+ Disponi di una singola istanza di database
+ Non utilizzate database collegabili (PDB)
+ Sono più semplici da gestire e migrare
+ In genere denominati ORCL in RDS Custom for Oracle

 **Multitenant (CDB con PDB)** 

Database container (CDB) che ospitano più database collegabili (PDB), introdotti in Oracle 12c. Questi database:
+ Disponi di un database di contenitori (CDB) con e `CDB$ROOT` `PDB$SEED`
+ Ospita uno o più database collegabili (PDB)
+ Fornisci il consolidamento del database e l'isolamento delle risorse
+ In genere denominato RDSCDB in RDS Custom for Oracle
+ Utilizza Oracle Managed Files (OMF) con le GUID-based sottodirectory per i file di dati PDB

**Nota importante per le migrazioni multitenant**: il database di destinazione verrà rinominato in ORCL durante il processo di migrazione (fonte: RDSCDB → destinazione: ORCL). Ciò semplifica la configurazione di destinazione e si allinea alle convenzioni di denominazione standard.

 **Principali differenze nell'approccio alla migrazione** 


|  **Aspetto**   |  **Non-CDB**  |  **Multitenant (CDB con PDB)**  | 
| --- | --- | --- | 
| **Ambito di migrazione** | Database singolo | Intero CDB con tutti i PDB | 
| **Post-migration state**  | Database aperto READ WRITE | CDB aperto READ WRITE; PDB in stato MOUNTED | 
| **Gestione PDB** | N/A | È necessario aprire i PDB e configurare l'apertura automatica | 
| **Pulizia** | Database singolo | CDB$ROOT(passa a cascata ai PDB); gestisce gli utenti comuni di C\#\# | 
| **Connessioni alle applicazioni** | Servizio di database | Servizi PDB (non CDB) | 
| **File di parametri** | Parametri standard | Richiede enable\_pluggable\_database=True | 
| **Complessità** | Minore | Maggiore a causa della presenza di più contenitori | 

## Prerequisiti comuni per entrambe le opzioni di migrazione
<a name="RDS-Custom-for-Oracle-end-of-support-common-prerequisites"></a>

Prima di avviare una delle due opzioni di migrazione, completa i seguenti passaggi preliminari:

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.

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

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

1. 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](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html). AWS CLI

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

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

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

1. Crea una struttura di directory su EC2

   La struttura delle cartelle dipende dall'architettura del database:  
**Example 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
   ```  
**Example 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.

1. Verifica la configurazione del database di origine

Prima di iniziare la migrazione, verifica la configurazione del database di origine:

1. Accedi all'host del database RDS Custom come utente rdsdb e imposta l'ambiente:  
**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 al database e verifica l'architettura:  
**Example**  

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

   ```
   NAME CDB OPEN_MODE                 LOG_MODE
   --------- --- -------------------- ------------
   ORCL NO  READ  WRITE               ARCHIVELOG
   ```  
**Example Per Multitenant (CDB), output previsto:**  

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

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

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

   Output previsto (esempio con 1 PDB denominato ORCLDB):  
**Example**  

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

1. Controlla la dimensione totale del database:  
**Example Per Non-CDB:**  

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

## Opzione 1: migrazione fisica tramite RMAN Active Duplication
<a name="RDS-Custom-for-Oracle-end-of-support-option-1"></a>

**Topics**
+ [Quando utilizzare la duplicazione attiva RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-when-to-use)
+ [Panoramica sulla duplicazione attiva di RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-overview)
+ [Flusso di lavoro di migrazione per la duplicazione attiva di RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-migration-workflow)
+ [Fase 1: mettere in pausa l'automazione personalizzata di Amazon RDS](#RDS-Custom-for-Oracle-end-of-support-option-1-step-1)
+ [Fase 2: Creare file di password e parametri](#RDS-Custom-for-Oracle-end-of-support-option-1-step-2)
+ [Fase 3: Trasferimento dei file su EC2](#RDS-Custom-for-Oracle-end-of-support-option-1-step-3)
+ [Fase 4: Modifica il file dei parametri su EC2](#RDS-Custom-for-Oracle-end-of-support-option-1-step-4)
+ [Fase 5: Configurare TNS e listener](#RDS-Custom-for-Oracle-end-of-support-option-1-step-5)
+ [Passaggio 6: avvia il database su EC2 `NOMOUNT`](#RDS-Custom-for-Oracle-end-of-support-option-1-step-6)
+ [Fase 7: Eseguire la duplicazione attiva di RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-step-7)
+ [Fase 8: Aprire i PDB (solo multitenant)](#RDS-Custom-for-Oracle-end-of-support-option-1-step-8)
+ [Passaggio 9: rimuovere gli oggetti RDS Custom](#RDS-Custom-for-Oracle-end-of-support-option-1-step-9)
+ [Fase 10: Configurazione dell'avvio automatico](#RDS-Custom-for-Oracle-end-of-support-option-1-step-10)
+ [Fase 11: Convalida finale](#RDS-Custom-for-Oracle-end-of-support-option-1-step-11)

Questa sezione fornisce i passaggi dettagliati per la migrazione del database Oracle da RDS Custom for Oracle a EC2 utilizzando la duplicazione attiva RMAN. Questo metodo esegue la duplicazione da un database attivo e in esecuzione, mantenendo il codice sorgente online e accessibile durante il processo di migrazione.

### Quando utilizzare la duplicazione attiva RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-when-to-use"></a>

Scegli la duplicazione attiva RMAN quando:
+ Desiderate mantenere il database di origine online e accessibile durante la migrazione
+ Puoi permetterti una breve finestra di dialogo per il reindirizzamento finale dell'applicazione
+ Desiderate un processo di migrazione semplice con un minor numero di parti mobili
+ Le dimensioni del database e la larghezza di banda della rete consentono tempi di duplicazione ragionevoli
+ Non è necessaria una sincronizzazione continua prima del cutover
+ Stai migrando database di produzione, sviluppo o test

### Panoramica sulla duplicazione attiva di RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-overview"></a>

La duplicazione attiva di RMAN non richiede un backup del database di origine o la messa offline del database di origine. Duplica il database di origine attivo e in esecuzione nella destinazione copiando i file del database sulla rete mentre l'origine rimane online e accessibile alle applicazioni.

**Principali vantaggi:**
+ L'**origine rimane online**: le applicazioni possono continuare ad accedere al database di origine durante la duplicazione
+ **Nessun backup richiesto**: elimina la necessità di uno storage di backup intermedio
+ **Trasferimento diretto in rete**: i file del database vengono copiati direttamente dall'origine alla destinazione
+ **Coerenza automatica: RMAN garantisce la coerenza** del database duplicato
+ **Operazione singola**: per il multitenant, duplica l'intero CDB, inclusi tutti i PDB, in un'unica operazione

Il processo di duplicazione crea una copia esatta del database di origine sulla destinazione, inclusi tutti i file di dati, i control file e i redo log. Il database di origine continua a soddisfare le richieste delle applicazioni durante tutto il processo di duplicazione. Alla fine è necessaria solo una breve finestra di dialogo per reindirizzare le applicazioni dall'origine alla destinazione.

**Cronologia tipica**

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

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

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

### Flusso di lavoro di migrazione per la duplicazione attiva di RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-migration-workflow"></a>

**Procedura dell'istanza DB personalizzata RDS (origine):**

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

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

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

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

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

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

1. Configura tnsnames.ora su EC2

1. Configura l'ambiente per l'istanza EC2

1. Configura Oracle Listener su EC2

1. Avvia il database su EC2 nello stato NOMOUNT

**Fasi di duplicazione RMAN:**

1. Eseguire la duplicazione attiva di RMAN

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

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

1. Rimuovi utenti e oggetti specifici di RDS Custom

1. Crea SPFILE e configura l'avvio automatico

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

### Fase 1: mettere in pausa l'automazione personalizzata di Amazon RDS
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-1"></a>

Metti in pausa la modalità di automazione sull'istanza RDS Custom prima di procedere con le fasi di migrazione per assicurarti che l'automazione non interferisca con l'attività RMAN. Il parametro --resume-full-automation-mode-minute (240 minuti = 4 ore in questo esempio) deve essere modificato in base alle dimensioni del database e al tempo di duplicazione previsto.

**Importante: la sospensione dell'automazione non influisce sulla disponibilità del database.** Il database rimane online e accessibile alle applicazioni durante il processo di duplicazione.

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

Convalida lo stato dell'automazione:

**Example**  

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

Output previsto: "» `all-paused`

### Fase 2: Creare file di password e parametri
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-2"></a>

Crea un file di password utilizzando`orapwd`. Recupera la password SYS da AWS Secrets Manager (memorizzata durante la creazione dell'istanza 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
```

Crea un file di parametri dal database di origine:

**Example**  

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

Il file dei parametri generato conterrà Custom-specific percorsi e parametri RDS. Per il multitenant, i parametri chiave includono:
+ `enable_pluggable_database`= `TRUE` (fondamentale per il multitenant)
+ `noncdb_compatible`= `TRUE` (per compatibilità con le versioni precedenti)
+ Percorsi dei file di dati per `CDB$ROOT` e tutti `PDB$SEED` i PDB
+ `db_create_file_dest`e `db_create_online_log_dest_1` per OMF

### Fase 3: Trasferimento dei file su EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-3"></a>

Scegli il metodo di trasferimento dei file che preferisci. Questa guida utilizza Amazon S3 a titolo di esempio.

 **Utilizzando Amazon S3:** 

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

**Example Per 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 Per 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
```

Convalida i file su EC2:

**Example**  

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

### Fase 4: Modifica il file dei parametri su EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-4"></a>

Il file dei parametri richiede un'attenta modifica per garantire il successo della migrazione. Questa è una delle fasi più importanti del processo di migrazione.

Esegui la modifica `$ORACLE_HOME/dbs/initORCL.ora` sull'istanza EC2 e apporta queste modifiche critiche:

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

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

1. 

**Rimuovi Custom-specific i parametri RDS**
   + `dg_broker_config_file1`e `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)

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

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

**Informazioni sui parametri di conversione dei nomi di file:** 

I `LOG_FILE_NAME_CONVERT` parametri `DB_FILE_NAME_CONVERT` and sono fondamentali per la duplicazione RMAN. Indicano a RMAN come mappare i percorsi dei file di origine ai percorsi dei file di destinazione durante il processo di duplicazione. Senza questi parametri, RMAN tenterà di creare file negli stessi percorsi dell'origine, operazione che avrà esito negativo su EC2.

**Considerazioni chiave:**
+ Ogni parametro accetta coppie di stringhe: percorso di origine seguito da percorso di destinazione
+ È possibile specificare più coppie in un singolo parametro
+ Per il multitenant, è necessario mappare i percorsi per e tutti i `CDB$ROOT` `PDB$SEED` PDB
+ L'ordine delle coppie è importante: RMAN le elabora nell'ordine specificato
+ I percorsi fanno distinzione tra maiuscole e minuscole e devono corrispondere esattamente

**Mappature dei percorsi:**


**Non-CDB:**  

|  **Percorso personalizzato RDS**  |  **Percorso EC2**  |  **Descrizione**  | 
| --- | --- | --- | 
| /rdsdbbin | //oracolo u01/app | Base Oracle | 
| /rdsdbdata/db/ORCL\_A/datafile/ | /u01/app/oracle/oradata/ORCL/datafile/ | File di dati | 
| /rdsdbdata/db/ORCL\_A/controlfile/ | /u01/app/oracle/oradata/ORCL/controlfile/ | File di controllo | 
| /rdsdbdata/db/ORCL\_A/onlinelog/ | /u01/app/oracle/oradata/ORCL/onlinelog/ | Redo log online | 
| /rdsdbdata/db/ORCL\_A/arch/ | /u01/app/oracle/oradata/ORCL/arch/ | Registri di archivio | 
| /rdsdbdata/admin/ORCL/adump | /u01/app/oracle/admin/ORCL/adump | Audit dump | 
| /rdsdbdata/log | //oracolo u01/app | Destinazione diagnostica | 


**Multitenant**  

|  **Percorso personalizzato RDS**  |  **Percorso EC2**  |  **Descrizione**  | 
| --- | --- | --- | 
| /rdsdbbin | /u01/app/oracle | Base Oracle | 
| /rdsdbdata/db/cdb/RDSCDB/datafile/ | /u01/app/oracle/oradata/ORCL/cdb/datafile/ | File di dati principali CDB | 
| /rdsdbdata/db/cdb/pdbseed/ | /u01/app/oracle/oradata/ORCL/pdbseed/datafile/ | PDB$SEEDfile di dati | 
| /rdsdbdata/db/pdb/RDSCDB\_A/ | /u01/app/oracle/oradata/ORCL/pdb/datafile/ | file di dati PDB (OMF con GUID) | 
| /rdsdbdata/db/cdb/RDSCDB\_A/controlfile/ | /u01/app/oracle/oradata/ORCL/controlfile/ | File di controllo | 
| /rdsdbdata/db/cdb/RDSCDB\_A/onlinelog/ | /u01/app/oracle/oradata/ORCL/onlinelog/ | Redo log online | 
| /rdsdbdata/db/cdb/RDSCDB\_A/arch/redolog | /u01/app/oracle/oradata/ORCL/arch/ | Registri di archivio | 
| /rdsdbdata/admin/RDSCDB/adump | /u01/app/oracle/admin/ORCL/adump | Audit dump | 
| /rdsdbdata/log | /u01/app/oracle | Destinazione diagnostica | 

**Aggiungi parametri di conversione:**

**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** (deve includere le mappature per la radice del CDB e tutti i percorsi PDB): `PDB$SEED`**  

```
*.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/'
```

**Importante**: per il multitenant, ensure = è presente nel file dei parametri. `enable_pluggable_database` `TRUE` RDS Custom utilizza OMF per i file di dati PDB con GUID-based sottodirectory: la mappatura dei percorsi lo gestisce automaticamente.

 **File di parametri di esempio completi:** 

**Example File di Non-CDB parametri di esempio (`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 Esempio di file di parametri 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/'
```

**Spiegazioni dei parametri chiave:**
+ `enable_pluggable_database=TRUE`: Richiesto per CDB multitenant. Questo parametro abilita la funzionalità di database collegabile.
+ `noncdb_compatible=TRUE`: impostato da RDS Custom per la compatibilità con le versioni precedenti. Può essere conservato o rimosso in base alle tue esigenze.
+ `db_create_file_dest`: specifica la posizione predefinita per Oracle Managed Files (OMF). Per il multitenant, indica la directory dei file di dati PDB.
+ `db_create_online_log_dest_1`: specifica la posizione per i redo log online quando si utilizza OMF.
+ `DB_FILE_NAME_CONVERT`: fondamentale per la duplicazione di RMAN. Mappa i percorsi dei file di dati di origine sui percorsi di destinazione.
+ `LOG_FILE_NAME_CONVERT`: mappa i percorsi di redo log di origine ai percorsi di destinazione.
+ `memory_target`e`memory_max_target`: regolali in base alla memoria dell'istanza EC2. I valori mostrati sono esempi.
+ `processes`: numero massimo di processi del sistema operativo che possono connettersi a Oracle. Modifica in base al carico di lavoro.

**Linee guida per il dimensionamento della memoria:**

Quando si regolano i parametri di memoria per l'istanza EC2:


|  **Memoria dell'istanza EC2**  |  **memory\_target consigliata**  |  **Memory\_max\_target consigliato**  | 
| --- | --- | --- | 
| 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) | 

Lascia circa il 20-25% della memoria di sistema per il sistema operativo e altri processi.

### Fase 5: Configurare TNS e listener
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-5"></a>

In entrambe le istanze, aggiungi le voci TNS a: `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 Configura il listener su 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 Avvia il listener:**  

```
lsnrctl start
```

**Nota**  
Per la duplicazione attiva di RMAN, le voci TNS si connettono all'istanza del database utilizzando SID (non SERVICE\_NAME). Per il multitenant, si connette al CDB e RMAN duplica automaticamente tutti i PDB.

### Passaggio 6: avvia il database su EC2 `NOMOUNT`
<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 Verifica i parametri:**  

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

### Fase 7: Eseguire la duplicazione attiva di RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-7"></a>

La duplicazione attiva RMAN copia il database dall'origine attiva e in esecuzione alla destinazione. Il database di origine rimane online e accessibile alle applicazioni durante tutto questo processo.

Connect RMAN sia all'istanza di origine che a quella di destinazione:

**Example**  

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

**Example Output previsto per dispositivi 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 previsto per 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 Esegui il comando di duplicazione attivo:**  

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

**Nota**  
L'**origine rimane online**: il database di origine continua a soddisfare le richieste delle applicazioni durante la duplicazione
**Per gli utenti non CDB**: questa operazione duplica l'intero database mentre rimane online
**Per utenti multitenant**: questa soluzione duplica l'intero CDB`CDB$ROOT`, compresi tutti i PDB, in un'unica `PDB$SEED` operazione, mentre il codice sorgente rimane online
**NOFILENAMECHECK**: consente a RMAN di procedere anche se i nomi dei file differiscono tra origine e destinazione
**Durata: dipende dalla dimensione del** database e dalla larghezza di banda della rete. Per un database da 100 GB, aspettati 30-60 minuti
**Impatto sulla rete:** utilizzo elevato della larghezza di banda di rete durante la duplicazione, ma il database di origine rimane accessibile

**Il processo di duplicazione attiva di RMAN include diverse fasi:**

1. Connessione ai database di origine e di destinazione

1. Creazione di un file `SPFILE` dalla memoria sulla destinazione

1. Ripristino del file di controllo sulla destinazione

1. Montaggio del database di destinazione

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

1. Ripristino del database di destinazione

1. Apertura del database di destinazione con `RESETLOGS`

**Durante la duplicazione, il database di origine:**
+ Rimane in modalità `READ WRITE`
+ Continua ad accettare connessioni
+ Elabora le transazioni normalmente
+ Genera normalmente i redo log
+ È completamente accessibile alle applicazioni

**Example Monitora i progressi in un'altra sessione:**  

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

 **Monitoraggio e risoluzione dei problemi dettagliati durante la duplicazione di RMAN:** 

Durante l'esecuzione della duplicazione RMAN, è possibile monitorarne l'avanzamento utilizzando diversi metodi:

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

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

1. **Monitora i canali 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. **Controlla il registro degli avvisi:**  
**Example 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`).

### Fase 8: Aprire i PDB (solo multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-8"></a>

Una volta completata la duplicazione RMAN, il CDB su EC2 è aperto in `READ WRITE` modalità, ma tutti i PDB sono attivi. `MOUNTED` Si tratta di un comportamento previsto: è necessario aprirli manualmente.

Controlla lo stato attuale del PDB:

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

Output previsto (esempio con un solo PDB denominato`ORCLDB`):

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

Apri tutti i PDB:

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

Verifica che tutti i PDB siano ora aperti in `READ WRITE` modalità:

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

Output previsto:

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

Configura l'apertura automatica all'avvio utilizzando il metodo save state (consigliato per Oracle 19c):

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

Questo indica a Oracle di ricordare lo stato attuale di apertura dei PDB e di ripristinarlo all'avvio del CDB.

Verifica lo stato salvato:

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

Verifica che i servizi PDB siano registrati con il listener:

```
lsnrctl services
```

L'output previsto dovrebbe mostrare i servizi per il CDB e ogni PDB. Se i servizi non vengono visualizzati:

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

Quindi ricontrolla con`lsnrctl services`.

### Passaggio 9: rimuovere gli oggetti RDS Custom
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-9"></a>

Poiché ora si tratta di un database autogestito su EC2, è necessario rimuovere gli utenti e gli oggetti RDS. Custom-specific Il processo di pulizia differisce tra le architetture non CDB e quelle multitenant.

**Importante**  
Prima di eliminare RDS-specific utenti e tablespace, verificate che non esistano oggetti applicativi in base a questi schemi:

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

Se vengono trovati oggetti applicativi, migrateli negli schemi applicativi appropriati prima di procedere.

**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 previsto: `no rows selected`

**Multitenant:**

In un ambiente multitenant, RDS Custom crea utenti comuni visibili su tutti i PDB. `CDB$ROOT` È necessario ripulire da. `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 previsto per tutte le query: `no rows selected`

### Fase 10: Configurazione dell'avvio automatico
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-10"></a>

Crea`SPFILE`:

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

Per chi utilizza più tenant, assicurati che i PDB siano aperti:

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

`/etc/oratab`Modifica:

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

### Fase 11: Convalida finale
<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>}}
```

 **Fase 12: Riprendere l'automazione RDS Custom** 

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

 

## Opzione 2: migrazione fisica con Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2"></a>



Questa sezione fornisce i passaggi dettagliati per la migrazione del database Oracle da RDS Custom for Oracle a EC2 utilizzando Oracle Data Guard. Questo metodo è adatto per le migrazioni che richiedono tempi di inattività minimi.

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

**Scegli Oracle Data Guard quando:**
+ Sono necessari tempi di inattività minimi (da secondi a minuti per il passaggio al digitale)
+ Stai migrando database di produzione o mission-critical
+ È necessaria una sincronizzazione continua prima del cutover
+ Desiderate una funzionalità di fallback integrata
+ È necessario testare il database di destinazione prima di effettuare la migrazione

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

Oracle Data Guard mantiene un database di standby sincronizzato inviando e applicando continuamente i redo log dal database principale. Quando sei pronto per completare la migrazione, esegui un passaggio che porta lo standby EC2 a quello principale con tempi di inattività minimi (da secondi a minuti). Per i database multitenant, Data Guard protegge automaticamente l'intero CDB, inclusi tutti i PDB. Il ripristino generato da qualsiasi PDB viene inviato allo standby e applicato al PDB corrispondente in standby.

### Flusso di lavoro di migrazione per Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-odg-workflow"></a>

**Fasi (principali) dell'istanza DB personalizzata RDS:**

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

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

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

1. Crea un file di password

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

1. Crea un file di parametri dal database di origine

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

1. Copia il file delle password nell'istanza EC2

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

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

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

1. Configura tnsnames.ora su entrambe le istanze

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

1. Abilita la configurazione di Oracle Data Guard

1. Configura fal\_server e fal\_client sull'istanza di standby EC2

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

1. Ripristina l'istanza in standby

1. Esegui la commutazione manuale

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

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

1. Rimuovi utenti e oggetti specifici di RDS Custom

1. Crea SPFILE e configura l'avvio automatico

### Fase 1: mettere in pausa l'automazione personalizzata di Amazon RDS
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-1"></a>

Metti in pausa la modalità di automazione sulla tua istanza RDS Custom. Il `--resume-full-automation-mode-minute` parametro deve essere modificato in base alle dimensioni del database e al tempo di configurazione di Data Guard previsto.

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

Convalida lo stato dell'automazione:

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

Output previsto: "» `all-paused`

### Passaggio 2: confermare la modalità di registro di archivio e `FORCE_LOGGING`
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-2"></a>

Oracle Data Guard richiede che il database primario sia in modalità di registro di archivio con la registrazione forzata abilitata:

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

Output previsto:

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

Se la registrazione forzata non è abilitata, esegui:

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

### Fase 3: Creare file di password e parametri
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-3"></a>

Crea un file di password utilizzando`orapwd`. Recupera la password SYS da 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
```

Crea un file di parametri dal database di origine:

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

### Fase 4: Eseguire il backup RMAN o utilizzare la duplicazione attiva
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4"></a>

Sono disponibili due opzioni per creare il database di standby:

#### Opzione A: backup online RMAN (consigliato per la maggior parte degli scenari)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4-a"></a>

Crea una directory di backup ed esegui il backup del 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';
```

**Nota**  
Per il multitenant, la parola chiave del database esegue automaticamente il backup dell'intero CDB, inclusi tutti i PDB.

#### Opzione B: duplicazione attiva (metodo alternativo)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4-b"></a>

Salta la fase di backup e utilizza la duplicazione attiva RMAN per creare lo standby direttamente sulla rete. Ciò elimina la necessità di archiviazione di backup e trasferimenti di file. Dopo aver configurato TNS e i listener (vedi sotto), esegui:

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

Questa guida si concentra sull'opzione A (basata sul backup), ma l'opzione B è un'alternativa valida.

### Fase 5: Trasferimento dei file su EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-5"></a>

Scegli il metodo di trasferimento dei file che preferisci. Questa guida utilizza Amazon S3 a titolo di esempio.

**Utilizzando Amazon S3:**

**Example Per 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 Per 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
```

### Passaggio 6: modifica del file dei parametri su EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-6"></a>

Modifica `$ORACLE_HOME/dbs/initORCL.ora` sull'istanza EC2 e apporta queste modifiche critiche:

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

1. **Cambia db\_unique\_name**: Da (o) a `ORCL_A` `RDSCDB_A` `ORCL_B`

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

1. 

****Rimuovi i parametri RDS Custom-specific****
   + `dg_broker_config_file1`e `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

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

 **Mappature dei percorsi:** 

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

**Importante**: per il multitenant, ensure `enable_pluggable_database` = `TRUE` è presente nel file dei parametri.

### Fase 7: Creare `SPFILE` e ripristinare il database in standby
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-7"></a>

Avvia l'istanza e crea 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;
```

Crea un link simbolico:

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

Avvia l'istanza e ripristina:

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

Se i file di backup si trovano in un percorso diverso da quello di origine, catalogali prima:

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

Ripristina il file di controllo in standby e monta:

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

Se i percorsi dei file di dati sono diversi (ad esempio, utilizzando ASM), usa`SET NEWNAME`:

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

Altrimenti, ripristina semplicemente:

```
RMAN> restore database;
```

Ripristina il database fino all'ultima sequenza disponibile:

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

**Nota**  
Per il multitenant, RMAN ripristina e recupera automaticamente tutti i PDB. Non è necessario ripristinare ogni PDB separatamente.

### Fase 8: Configurare TNS e ascoltatori
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-8"></a>

In entrambe le istanze, aggiungi le voci TNS a: `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)))
```

Configura i listener su entrambe le istanze. Su RDS Custom, aggiungi a: `listener.ora`

**Example Per: 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 Per 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>}})))
```

Avvia l'ascoltatore:

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

Su EC2, crea: `$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>}})))
```

Avvia l'ascoltatore:

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

**Nota**  
Se preferisci, puoi utilizzare il listener esistente su RDS Custom, ma la creazione di un listener Data Guard separato offre un isolamento migliore.

**Importante**  
Se `tnsping` la nostra `listener` connettività fallisce, controlla `iptables` le regole su EC2. Molte istanze Linux EC2 hanno `iptables` regole predefinite che bloccano la porta 1521. Aggiungi una regola: `sudo iptables -I INPUT 5 -p tcp --dport 1521 -j ACCEPT`

### Passaggio 9: abilitare il broker e la configurazione di Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-9"></a>

In entrambe le istanze, abilita il broker Data Guard:

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

Sul primario RDS Custom, connettiti al broker Data Guard e crea la configurazione:

```
dgmgrl /
```

**Example Per 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 Per 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;
```

Imposta gli identificatori di connessione statici e abilita:

 

**Example Per 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 Per 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;
```

**Nota**  
Il broker Data Guard è facoltativo ma consigliato per una gestione più semplice. Per migrazioni semplici, puoi configurare Data Guard manualmente senza il broker.

**Nota**  
Quando abiliti Data Guard per un CDB, protegge automaticamente tutti i PDB. Il ripristino generato da qualsiasi PDB viene inviato allo standby e applicato al PDB corrispondente in standby.

### Passaggio 10: configura i redo log in standby e avvia il ripristino
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10"></a>

Nell'istanza di standby EC2, aggiungi i redo log file in standby (n\+1 dove n è il numero di gruppi di redo log 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;
```

**Nota**  
Per i sistemi multitenant, i redo log in standby vengono creati a livello di CDB e sono condivisi da tutti i PDB.

Configura i parametri FAL in standby:

 

**Example Per: Non-CDB**  

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

 

**Example Per Multitenant:**  

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

Avvia il ripristino gestito:

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

Monitora il ritardo di applicazione:

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

**Monitoraggio e gestione dettagliati della sincronizzazione di Data Guard:**

Il monitoraggio di Data Guard è fondamentale per garantire una migrazione di successo. Ecco alcune tecniche di monitoraggio complete:

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

1. **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;
   ```

1. **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;
   ```

1. **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;
   ```

1. **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';
   ```

1. **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;
   ```

#### Problemi comuni di sincronizzazione di Data Guard:
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues"></a>



##### Problema 1: ritardo di applicazione elevato
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-1"></a>

Caratteristiche:

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

Cause e soluzioni:
+ **Insufficiente CPU/IO in standby**: aggiorna il tipo di istanza EC2 o aumenta gli IOPS EBS
+ **Limitazione della larghezza di banda di rete**: utilizza reti avanzate o tipi di istanze con larghezza di banda superiore
+ **PDB multipli con elevata velocità di transazione**: valuta la possibilità di aumentare il parallelismo Redo Apply (richiede una licenza 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;
```

##### Problema 2: lacuna nei registri di archiviazione
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-2"></a>

Caratteristiche:

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

Soluzione::

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

##### Problema 3: errore di trasporto Redo
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-3"></a>

Caratteristiche:

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

Soluzione::

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

##### Problema 4: ripristino gestito che non applica il ripristino
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-4"></a>

Caratteristiche:

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

Soluzione::

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

**Per Multitenant**, puoi anche controllare lo stato di ogni PDB in standby:

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

Output previsto (PDB in stato di standby): `MOUNTED`

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

**Nota**  
In uno standby fisico, i PDB rimangono in `MOUNTED` stato durante il ripristino gestito.

### Fase 11: Eseguire lo switchover
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-11"></a>

Dopo aver verificato che lo standby sia completamente sincronizzato e pronto, esegui il passaggio. Per il multitenant, lo switchover commuterà l'intero CDB (tutti i PDB) dal primario RDS Custom allo standby EC2.

Sull'istanza primaria RDS Custom, connettiti al broker Data Guard e verifica che entrambi i database siano pronti per il passaggio:

**Example Per: Non-CDB**  

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

 

**Example Per Multitenant:**  

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

Entrambi dovrebbero apparire `Ready for Switchover: Yes`

Passa dal primario RDS Custom allo standby EC2:

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

Verifica che il passaggio sia avvenuto correttamente:

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

L'istanza EC2 (`ORCL_B`) è ora il database principale e l'istanza RDS Custom è lo standby fisico.

### Fase 12: Aprire i PDB (solo multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-12"></a>

Dopo il passaggio, il CDB su EC2 è aperto in modalità READ WRITE, ma tutti i PDB sono nello stato MOUNTED. È necessario aprirli manualmente.

Connect al nuovo sistema primario su EC2:

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

Output previsto:

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

Controlla lo stato attuale del PDB:

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

Output previsto (PDB in `MOUNTED` stato, esempio con un PDB denominato): `ORCLDB`

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

Apri tutti i PDB:

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

Database collegabile alterato.

Verifica che tutti i PDB siano ora aperti in modalità: `READ WRITE`

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

Output previsto:

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

### Passaggio 13: configura l'apertura automatica del PDB all'avvio (solo multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-13"></a>

Configura i PDB in modo che si aprano automaticamente all'avvio del CDB utilizzando il metodo save state (consigliato per Oracle 19c):

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

Verifica lo stato di salvataggio:

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

Verifica che i servizi PDB siano registrati con il listener:

```
lsnrctl services
```

L'output previsto dovrebbe mostrare i servizi per il CDB e ogni PDB. Se i servizi non vengono visualizzati:

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

Quindi ricontrolla con`lsnrctl services`.

### Passaggio 14: rimuovere gli oggetti RDS Custom
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-14"></a>

Poiché ora si tratta di un database autogestito su EC2, è necessario rimuovere utenti e oggetti specifici di RDS Custom. Il processo di pulizia differisce leggermente tra le architetture non CDB e quelle multitenant.

**Importante**  
Prima di eliminare RDS-specific utenti e tablespace, verificate che non esistano oggetti applicativi in base a questi schemi:

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

Se vengono trovati oggetti applicativi, migrateli negli schemi applicativi appropriati prima di procedere.

**Non-CDB pulizia:**

```
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 previsto: `no rows selected`

**Pulizia multitenant:**

In un ambiente multitenant, RDS Custom crea utenti comuni visibili su tutti i PDB. `CDB$ROOT` È necessario ripulire da. `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 previsto per tutte le query: nessuna riga selezionata

### Fase 15: Configurare l'avvio automatico
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-15"></a>

Verifica che `SPFILE` sia in uso:

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

Se il `spfile` percorso è corretto, non è necessaria alcuna azione. In caso contrario, creane uno:

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

Riavvia il database:

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

Per il multitenant, apri tutti i PDB (dovrebbero aprirsi automaticamente se hai salvato lo stato in precedenza):

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

Se i PDB non sono aperti, apriteli manualmente:

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

Modifica`/etc/oratab`:

```
vi /etc/oratab
```

Cambia la riga `ORCL` da `N` a`Y`:

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

### Fase 16: Convalida finale
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-16"></a>

Esegui una convalida completa sul database migrato.

**Example Per: 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 Per 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>}}
```

Verifica la connettività delle applicazioni:

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

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

### Passaggio 17: pulire i file di backup
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-17"></a>

Al termine della convalida, rimuovi i file di backup e scollega il volume di backup se utilizzi un volume EBS separato:

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

Se utilizzi un volume EBS separato per i 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>}}
```

### Fase 18: Riprendere l'automazione personalizzata di RDS
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-18"></a>

Se prevedi di mantenere l'istanza RDS Custom in esecuzione come riserva durante un periodo di convalida, riprendi l'automazione:

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

## Risoluzione dei problemi comuni
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting"></a>



Questa sezione descrive i problemi più comuni che potresti riscontrare durante la migrazione sia per la duplicazione RMAN che per gli approcci Oracle Data Guard, coprendo sia le architetture non CDB che quelle multitenant.

### ORA-09925: Impossibile creare il file di audit trail
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-09925"></a>

**Causa:** la directory di audit specificata nel `audit_file_dest` parametro non esiste nell'istanza EC2 di destinazione.

 **Soluzione:**: 

Assicurati che la directory di controllo esista e disponga delle autorizzazioni appropriate:

```
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: La stringa di `db_create_file_dest` destinazione del parametro non può essere tradotta
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-01261"></a>

**Causa:** la directory specificata nel `db_create_file_dest` parametro non esiste nell'istanza EC2 di destinazione.

 **Soluzione:**: 

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

Per più tenant:

```
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: errore di inizializzazione delle informazioni sul fuso orario
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-01804"></a>

Questo errore può verificarsi quando si elimina l'`RDSADMIN`utente se la sorgente RDS ha una versione di fuso orario superiore a quella installata nel tuo $ORACLE\_HOME EC2.

 **Soluzione:**: 

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

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

1. Riprova il rilascio:

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

### Cross-RU problemi di migrazione (diversi aggiornamenti di versione)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-cross-ru-migration"></a>

**Causa:** l'istanza EC2 di destinazione ha una patch Oracle Release Update (RU) diversa o una tantum rispetto all'istanza RDS Custom di origine, il che causa errori di compatibilità durante o dopo la migrazione.

**Errori comuni:**
+ ORA-00600 errori interni durante la ripetizione dell'applicazione (Data Guard)
+ ORA-39700 il database deve essere aperto con l'opzione `UPGRADE`
+ Incoerenze nel dizionario dopo la migrazione
+ Oggetti non validi in o `DBA_REGISTRY` `DBA_OBJECTS`

 **Soluzione:**: 

 **Procedura consigliata: abbina esattamente le versioni RU e le patch una tantum:** 

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

1. Verifica il livello di patch $ORACLE\_HOME:

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

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

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

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

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

### Eventi di connettività di rete
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-network-connectivity"></a>

 

**Causa:** gruppi di sicurezza, ACL di rete o `iptables` blocco della porta del listener Oracle.

 **Soluzione:**: 

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

1. Controlla iptables su EC2:

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

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

1. Verifica la connettività:

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

### I PDB non si aprono dopo la migrazione (solo multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdbs-not-opening"></a>

**Causa:** si tratta di un comportamento previsto. Dopo la duplicazione di RMAN o il passaggio a Data Guard, il CDB è aperto ma i PDB sono attivi. `MOUNTED`

 **Soluzione:**: 

Aprirli manualmente:

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

Se un PDB specifico non riesce ad aprirsi, controlla la presenza di errori nel registro degli avvisi:

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

Le cause più comuni includono file di dati mancanti o problemi di mappatura dei percorsi.

### File di dati PDB non trovati o mancata corrispondenza del percorso (solo multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdb-data-files-not-found"></a>

**Causa:** la migrazione non ha mappato correttamente tutti i percorsi di origine, specialmente per i file di dati PDB. OMF-based 

 **Soluzione:**: 

1. Controlla quali file di dati mancano:

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

1. 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';
   ```

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

### Servizi PDB non registrati con listener (solo multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdb-services-not-registering"></a>

**Causa:** il listener non è a conoscenza dei servizi PDB dopo l'apertura dei PDB.

 **Soluzione:**: 

1. Registrazione forzata del servizio:

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

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

1. Verifica con:

   ```
   lsnrctl services
   ```

### I PDB non si aprono automaticamente dopo il riavvio del CDB (solo multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdbs-not-opening-after-cdb-restart"></a>

**Causa: lo stato di salvataggio del PDB** non è stato configurato.

 **Soluzione:**: 

Verifica che lo stato di salvataggio del PDB sia stato configurato:

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

Se non viene restituita alcuna riga, salva lo stato:

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

### Data Guard Redo Transport non funziona
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-odg-redo-transport-failure"></a>

**Causa:** problemi di connettività di rete, configurazione TNS errata o parametri FAL non impostati.

 **Soluzione:**: 

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

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

1. Verifica che fal\_server e fal\_client siano impostati correttamente in standby:

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

1. Verifica la connettività di rete:

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

1. Controlla il parametro log\_archive\_dest\_2 sui punti principali di standby (se configurato manualmente senza broker).

 **Data Guard applica un ritardo crescente con più PDB (solo multitenant)** 

**Causa:** per i CDB con più PDB, redo apply può essere più lenta a causa del volume delle modifiche su tutti i contenitori.

 **Soluzione:**: 

1. Controlla la tariffa di applicazione:

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

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

1. Verifica che non vi siano vincoli di risorse (CPU I/O) sull'istanza di standby.

 **Il backup del registro di archivio RMAN non riesce con ORA-19625** 

**Causa:** l'automazione RDS Custom ha eliminato i vecchi registri di archivio dal disco, ma il file di controllo di RMAN ne contiene ancora le registrazioni.

 **Soluzione:**: 

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

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

1. 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;
   }
   ```

### L'eliminazione comune da parte degli utenti non riesce in modalità multitenant (solo multitenant)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-multitenant-user-drop-fails"></a>

 

**Causa: la clausola** deve essere eliminata dagli utenti comuni (con il prefisso C\#\#). `CONTAINER=ALL`

 **Soluzione:**: 

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

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

Verifica di essere connesso a: `CDB$ROOT`

```
SQL> SHOW CON_NAME;
```

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

Dopo una migrazione riuscita, completa queste attività aggiuntive per assicurarti che il database Oracle autogestito su EC2 sia pronto per la produzione.

 **Aggiorna le stringhe di connessione dell'applicazione** 

**Per Non-CDB:**
+ Indirizza le tue applicazioni verso il nuovo endpoint dell'istanza EC2
+ Aggiorna le stringhe di connessione per utilizzare l'IP o il nome host dell'istanza EC2
+ Testa a fondo tutte le funzionalità dell'applicazione

**Per Multitenant:**
+ Indirizza le tue applicazioni verso i nuovi nomi di servizio PDB delle istanze EC2 (ad esempio, ORCLDB o i tuoi nomi PDB specifici)
+ Assicurati che le applicazioni si connettano al PDB corretto, non al CDB
+ Aggiorna le stringhe di connessione per utilizzare i nomi dei servizi PDB
+ Verifica tutte le funzionalità dell'applicazione per ogni PDB

Stringhe di connessione di esempio:

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

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

 **Configura la strategia di backup** 

Imposta una strategia di backup completa per il tuo database autogestito:

**Backup RMAN:**
+ Configura script di backup RMAN automatizzati per backup completi, incrementali e dei log di archivio
+ Imposta le politiche di conservazione dei backup in base agli obiettivi dei punti di ripristino (RPO)
+ Archivia i backup su Amazon S3 per durabilità ed economicità
+ Verifica regolarmente le procedure di ripristino dei backup

**AWS Backup:**
+ Utilizzare [AWS Backup](https://aws.amazon.com/backup/)per le istantanee dei volumi EBS
+ Configura le pianificazioni di backup e le politiche di conservazione
+ Abilita copie di backup su più regioni per il disaster recovery

**Per Multitenant:**
+ I backup RMAN del CDB includono automaticamente tutti i PDB
+ Se necessario, puoi anche eseguire il backup di singoli PDB
+ Prendi in considerazione le pianificazioni di PDB-specific backup in base ai requisiti aziendali

Esempio di script di backup 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
```

 **Configura il monitoraggio** 

Implementa un monitoraggio completo per il tuo database EC2-hosted Oracle:

**Amazon CloudWatch**
+ Configura le CloudWatch metriche per lo stato delle istanze EC2, l'utilizzo del disco e le metriche Oracle personalizzate
+ Crea CloudWatch allarmi per le soglie critiche
+ Usa CloudWatch Logs per il monitoraggio dei registri degli avvisi del database

**Oracle Enterprise Manager (OEM):**
+ Se disponibile, configura OEM per il monitoraggio del database
+ Configura il monitoraggio e la diagnostica delle prestazioni
+ Configura avvisi automatici per eventi critici

**Third-party strumenti:**
+ Prendi in considerazione strumenti come Datadog, New Relic o Prometheus per il monitoraggio dei database
+ Effettua l'integrazione con la tua infrastruttura di monitoraggio esistente

**Metriche chiave da monitorare:**
+ Utilizzo del tablespace
+ Spazio di archiviazione dei log
+ Oggetti non validi
+ Conteggi delle sessioni
+ Eventi di attesa
+ Utilizzo della CPU e della memoria
+ I/O prestazioni

**Per Multitenant:**
+ Monitora entrambi e le metriche CDB-level PDB-level 
+ Imposta avvisi per l'utilizzo e le quote delle risorse PDB
+ Tieni traccia delle metriche delle prestazioni PDB-specific 

 **Configura i gruppi di sicurezza e gli ACL di rete** 

Rivedi e rafforza la sicurezza per l'istanza EC2:

**Gruppi di sicurezza:**
+ Limita l'accesso alle porte del database solo agli application server e agli host bastion autorizzati
+ Rimuovi tutte le regole eccessivamente permissive create durante la migrazione
+ Regole dei gruppi di sicurezza dei documenti e relativi scopi

**ACL di rete:**
+ Configura gli ACL di rete VPC per livelli di sicurezza aggiuntivi
+ Implementa una strategia di sicurezza di difesa approfondita

**Accesso SSH:**
+ Limita l'accesso SSH a intervalli IP specifici o usa AWS Systems Manager Session Manager
+ Disabilita l'autenticazione tramite password e utilizza solo l'autenticazione basata su chiavi
+ Implementazione dell'autenticazione a più fattori (MFA) per l'accesso privilegiato

**Crittografia:**
+ Abilita la crittografia a riposo per i volumi EBS
+ Abilita la crittografia in transito per le connessioni al database utilizzando Oracle Native Network Encryption o TLS
+ Ruota regolarmente le chiavi di crittografia

**Implementa l'alta disponibilità**

Se il tuo carico di lavoro richiede un'elevata disponibilità, prendi in considerazione l'implementazione di:

**Oracle Data Guard:**
+ Configura un nuovo database in standby su un'altra istanza EC2 per il disaster recovery
+ Per chi è multitenant, Data Guard protegge l'intero CDB, inclusi tutti i PDB
+ Lo standby può trovarsi in una zona o regione di disponibilità diversa
+ Implementa meccanismi di failover automatizzati utilizzando script o strumenti di terze parti

**AWS Multi-AZ implementazione:**
+ Implementa istanze di standby in diverse zone di disponibilità
+ Usa Amazon Route 53 per il failover DNS
+ Implementa il pooling di connessioni a livello di applicazione con supporto per il failover

**Backup e ripristino:**
+ Mantenete backup regolari con procedure di ripristino testate
+ Documenta gli obiettivi del tempo di ripristino (RTO) e gli obiettivi dei punti di ripristino (RPO)
+ Conduci regolarmente esercitazioni di disaster recovery

**Esegui test approfonditi delle applicazioni**

Prima di disattivare l'istanza RDS Custom:

**Test funzionali:**
+ Verifica che tutte le funzionalità dell'applicazione funzionino correttamente
+ Verifica tutte le funzionalità dipendenti dal database
+ Convalida l'integrità e la coerenza dei dati

**Test delle prestazioni:**
+ Confronta le metriche delle prestazioni con la linea di base RDS Custom
+ Identifica e risolvi eventuali regressioni delle prestazioni
+ Ottimizza le query e gli indici secondo necessità

**Test di carico:**
+ Esegui il test del database in base ai picchi di carico previsti
+ Verifica che l'utilizzo delle risorse rimanga entro limiti accettabili
+ Identifica e risolvi eventuali problemi

**Test di failover (se HA è configurato):**
+ Scenari di failover dei test
+ Verifica la logica di riconnessione delle applicazioni
+ Misura l'RTO e l'RPO effettivi

**Test di backup e ripristino:**
+ Verifica del corretto funzionamento delle procedure di backup e ripristino
+ Prova il ripristino point-in-time
+ Convalida l'integrità del backup

**Per Multitenant:**
+ Testa ogni PDB in modo indipendente
+ Verifica l'isolamento del PDB e l'allocazione delle risorse
+  PDB-specific Operazioni di test (clonazione unplug/plug, ecc.)

**Disattiva l'istanza personalizzata RDS**

Dopo un periodo di convalida riuscito (in genere 1-2 settimane):

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

1. **Documenta la migrazione**: aggiorna i runbook e la documentazione con la nuova configurazione EC2

1. **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
   ```

1. **Pulisci le risorse**: rimuovi le istantanee, i gruppi di parametri e i gruppi di opzioni associati se non sono più necessari

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

## Confronto: RMAN Active Duplication e Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-RMAN-vs-ODG"></a>

La tabella seguente riassume le principali differenze tra le due opzioni di migrazione:


|  **Aspetto**  |  **Duplicazione attiva RMAN**  |  **Oracle Data Guard**  | 
| --- | --- | --- | 
| **Disponibilità del database di origine** | Online durante l'intera duplicazione | Online durante l'intero processo | 
| **Tempo di inattività** | Minuti (solo versione finale) | Da secondi a minuti (commutazione) | 
| **Complessità** | Più basso | Più alto | 
| **Durata della migrazione** | Operazione di duplicazione singola | Configurazione iniziale\+sincronizzazione continua | 
| **Sincronizzazione continua** | No | Sì | 
| **Capacità di fallback** | Manuale (mantieni il codice sorgente in esecuzione) | Built-in (automatico) | 
| **Test prima del taglio** | Limitato (test dopo la duplicazione) | Possibilità di test completi (è possibile testare la modalità standby) | 
| **Larghezza di banda della rete** | Alta durante la duplicazione | Moderato (continuo) | 
| **Impatto sul database di origine** | Minimo (operazioni di lettura) | Minimo (rifai la spedizione) | 
| **Ideale per** | La maggior parte delle migrazioni è semplice | Mission-critical, sono richiesti tempi di inattività quasi nulli | 
| **Non-CDB supporto** | Sì  | Sì | 
| **supporto multi-tenant** | Sì (intero CDB) | Sì (intero CDB) | 
| **Post-migration Stato PDB** | CDB aperto, PDB MONTATI | CDB aperto, PDB MONTATI | 
| **Richiede RMAN** | Sì | Sì (per il backup iniziale in un approccio basato sul backup) | 
| **Richiede Data Guard** | No | Sì | 
| **Livello di abilità richiesto** | Intermedia | Avanzata | 
| **Processo di taglio** | Reindirizza le applicazioni a EC2 | Comando Switchover \+ applicazioni di reindirizzamento | 

## Confronto: rispetto alla migrazione multitenant Non-CDB
<a name="RDS-Custom-for-Oracle-end-of-support-non-cdb-va-multitenant"></a>

 

La tabella seguente riassume le principali differenze tra la migrazione di database non CDB e multitenant:


|  **Aspetto**  |  **Non-CDB migrazione**  |  **Migrazione multitenant (CDB con PDB)**  | 
| --- | --- | --- | 
| **Tipo di database** | Single-instance Non CDB (ad esempio,) ORCL | CDB (fonte:RDSCDB, destinazione:ORCL) con CDB$ROOT \+ PDB$SEED \+ uno o più PDB | 
| **Ambito di migrazione** | Database singolo | CDB completo (tutti i PDB inclusi automaticamente) | 
| **Ambito di duplicazione RMAN** | Duplica un singolo database | Duplica l'intero CDB (tutti i contenitori) | 
| **Scopo di Data Guard** | Protegge un singolo database | Protegge l'intero CDB (tutti i PDB inclusi automaticamente) | 
| **File di parametri** | Parametri di inizializzazione standard | Deve includere = enable\_pluggable\_database TRUE | 
| **Post-migration stato del database** | Il database si apre in modalità READ WRITE | CDB si apre in READ WRITE modalità; i PDB rimangono nello stato MOUNTED | 
| **Apertura del PDB** | N/A | È necessario aprire manualmente tutti i PDB con ALTER PLUGGABLE DATABASE ALL OPEN | 
| **Apertura automatica del PDB all'avvio** | N/A | È necessario configurare lo stato di salvataggio del PDB o il trigger di avvio | 
| **Convalida** | Controlli su un singolo database | È necessario convalidare CDB e ogni PDB singolarmente | 
| **RDS-specific pulire** | Eliminazione users/objects da un singolo database | Elimina gli utenti comuni da CDB$ROOT (passa a cascata ai PDB); gestisci gli utenti C\#\# | 
| **TNS/Listener configurazione** | Servizio unico per database | Servizio CDB \+ servizi PDB individuali registrati dinamicamente | 
| **Stringhe di connessione all'applicazione** | Connect a un unico database | Connect a singoli servizi PDB (non CDB) | 
| **Strategia di Backup** | Backup di un singolo database | Backup dell'intero CDB (include tutti i PDB) o di singoli PDB | 
| **Gestione delle risorse** | Database-level gestione delle risorse | CDB-level e gestione PDB-level delle risorse con Resource Manager | 
| **Complessità** | Minore complessità | Maggiore complessità grazie a più contenitori e percorsi OMF | 

## Best practice e raccomandazioni
<a name="RDS-Custom-for-Oracle-end-of-support-best-practices"></a>

Questa sezione fornisce best practice complete per una migrazione di successo da RDS Custom for Oracle a EC2.

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

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

1. Scegli il tipo di istanza EC2 giusto:

   Seleziona un tipo di istanza EC2 in base alle caratteristiche del tuo carico di lavoro:    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/RDS-Custom-for-Oracle-end-of-support.html)

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

1. Progetta la tua architettura di storage:

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

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

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

### Best practice per l'esecuzione della migrazione
<a name="RDS-Custom-for-Oracle-end-of-support-migration-best-practices"></a>

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

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

1. **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;
   ```

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

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

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

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

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

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

### Ottimizzazione dei costi
<a name="RDS-Custom-for-Oracle-end-of-support-cost-optimization"></a>

 **1. Right-sizing**: 

Dopo la migrazione, monitora e ottimizza i costi:
+ **Usa AWS Cost Explorer** per analizzare i costi di EC2 ed EBS
+ **Abilita AWS Compute** Optimizer per esempio, consigli sui tipi di esempio
+ **Rivedi le CloudWatch metriche per identificare le risorse** sottoutilizzate
+ **Prendi in considerazione Reserved Instances** o Savings Plans per carichi di lavoro prevedibili

 **2. Ottimizzazione dello spazio di archiviazione:** 
+ **Implementa le politiche del ciclo di vita** per i backup S3 (passa a Glacier dopo 30 giorni)
+ **Elimina regolarmente le** istantanee EBS non utilizzate
+ **Usa gp3 anziché gp2 per risparmiare sui costi a parità di prestazioni**
+ **Scollega ed elimina i volumi** di backup al termine della migrazione

 **3. Automazione:** 
+ **Automatizzazione** dei database non start/stop di produzione durante le ore non lavorative
+ **Usa AWS Systems Manager** per la gestione delle patch
+ **Implementa l'auto-scaling** per le repliche di lettura se utilizzi Data Guard

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

Questa guida prescrittiva ha fornito strategie di migrazione dettagliate per spostare i database Oracle da Amazon RDS Custom for Oracle ai database Oracle autogestiti su Amazon EC2. Con l'obsolescenza del servizio RDS Custom for Oracle a partire dal 31 marzo 2027, è importante pianificare ed eseguire la migrazione con largo anticipo.

 **Punti chiave** 

 **Opzioni di migrazione:** 
+ **Duplicazione attiva RMAN**: ideale per la maggior parte delle migrazioni, mantiene online il database di origine durante la duplicazione, richiede solo una breve finestra di dialogo per il reindirizzamento delle applicazioni
+ **Oracle Data Guard**: ideale per carichi di lavoro mission critical che richiedono tempi di inattività quasi nulli, grazie alla sincronizzazione continua e alla funzionalità di switchover integrata

 **Supporto dell'architettura:** 
+ Entrambe le opzioni di migrazione supportano architetture non CDB (tradizionale a istanza singola) e multitenant (CDB con PDB)
+ Per il multitenant, entrambi i metodi gestiscono automaticamente l'intero CDB, inclusi tutti i PDB, in un'unica operazione
+ I PDB richiedono l'apertura manuale e l'apertura automatica della configurazione dopo la migrazione

 **Fattori critici di successo:** 
+ Configurazione di rete e connettività corrette tra origine e destinazione
+ Compatibilità esatta tra le versioni (versione principale, versione secondaria, Release Update e patch una tantum)
+ Larghezza di banda di rete adeguata per il trasferimento dei dati (RMAN) o il redo shipping (Data Guard)
+ Tenendo conto del fatto che la duplicazione attiva di RMAN mantiene il codice sorgente online, è sufficiente una breve panoramica
+ Test e convalida approfonditi prima dello smantellamento della fonte
+ Attività complete successive alla migrazione, tra cui backup, monitoraggio e configurazione di sicurezza

 **Fasi successive:** 

1. Valuta l'architettura del tuo database (non CDB o multitenant)

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

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

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

1. Esegui convalide e test approfonditi

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

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

 **Altre risorse** 
+ [Guida per l'utente di Amazon RDS Custom per Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom.html)
+ [Documentazione del database Orac](https://docs.oracle.com/en/database/)
+ [Documentazione Oracle RMAN](https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/)
+ [Documentazione Oracle Data Guard](https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/)
+ [AWS Servizio di migrazione del Database](https://aws.amazon.com/dms/)
+ [AWS Guida prescrittiva](https://aws.amazon.com/prescriptive-guidance/)

 **Support** 

Per assistenza con la migrazione:
+ Contatta il AWS supporto tramite la console AWS di gestione
+ Rivolgiti all'assistenza Oracle per domande specifiche sul database

## **Informazioni sul documento**
<a name="RDS-Custom-for-Oracle-end-of-support-document-information"></a>

**Ultimo aggiornamento:** marzo 2026

**Contributori:**
+ Sharath Chandra Kampili, Architetto di soluzioni specializzato in database, Amazon Web Services
+ Ibrahim Emara, Architetto di soluzioni specializzato in database, Amazon Web Services
+ Vetrivel Subramani, Architetto di soluzioni specializzato in database, Amazon Web Services