Eseguire la migrazione a Oracle Exadata Database Service on Dedicated Infrastructure

Questa sezione descrive come eseguire la migrazione dei carichi di lavoro Oracle Exadata a Oracle Exadata Database Service on Dedicated Infrastructure ed eseguire la migrazione delle applicazioni VMware in Oracle Cloud VMware Solution.

Architettura

Questa architettura mostra una migrazione da database Oracle Exadata on premise e applicazioni VMware a Oracle Exadata Database Service on Dedicated Infrastructure e Oracle Cloud VMware Solution.

Utilizzando Oracle Zero Downtime Migration, automatizzare la migrazione del database e, al contempo, usufruire di un tempo di inattività minimo durante la migrazione dei dati da ambienti on premise al cloud.

Esegui la migrazione delle tue applicazioni on premise in esecuzione su VMware in Oracle Cloud VMware Solution utilizzando gli strumenti VMware come HCX e vMotion. Oracle Cloud VMware Solution ti offre un'implementazione completamente automatica di un data center (SDDC) definito dal software VMware all'interno della tua tenancy OCI, in esecuzione sulle istanze Bare Metal OCI.

Il diagramma riportato di seguito illustra questa architettura di riferimento.

Segue la descrizione di migrate-vmware-cloud-solution-exadata-dedicated-architecture.png

Descrizione dell'illustrazione migration-vmware-cloud-solution-exadata-dedicated-architecture.png

migra-vmware-cloud-solution-exadata-dedicated-architecture.zip

Questa architettura supporta i componenti elencati di seguito.

Area
Un'area Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, definiti domini di disponibilità. Le regioni sono indipendenti da altre regioni e grandi distanze possono separarle (in tutti i paesi o anche in continenti).
Rete cloud virtuale (VCN) e subnet
Una VCN è una rete personalizzabile e definita dal software configurata in un'area Oracle Cloud Infrastructure. Analogamente alle reti di data center tradizionali, i VCN offrono il controllo completo sull'ambiente di rete. Una VCN può avere più blocchi CIDR non sovrapposti che puoi modificare dopo aver creato la VCN. Puoi segmentare una VCN nelle subnet che possono essere definite nell'area o in un dominio di disponibilità. Ogni subnet è composta da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet nella VCN. Puoi modificare le dimensioni di una subnet dopo la creazione. Una subnet può essere pubblica o privata.
Oracle Exadata Database Service on Dedicated Infrastructure
Oracle Exadata Database Service on Dedicated Infrastructure offre Oracle Exadata Database Machine come servizio in un data center OCI. Il servizio Oracle Exadata Database Service on Dedicated Infrastructure può ospitare molti database Oracle in esecuzione in uno o più cluster VM che vengono eseguiti su un singolo rack Exadata in un'area OCI. Oracle Exadata Database Service on Dedicated Infrastructure è una piattaforma ideale per il consolidamento dei database.
Oracle Cloud VMware Solution - Software-Defined Data Center (SDDC)
Oracle e VMware hanno collaborato per sviluppare un'implementazione Software-Defined Data Center (SDDC) certificata VMware da utilizzare in Oracle Cloud Infrastructure. Questa implementazione, denominata Oracle Cloud VMware Solution, utilizza Oracle Cloud Infrastructure per ospitare un SDDC VMware ad alta disponibilità. Consente inoltre la migrazione trasparente di tutti i carichi di lavoro dell'SDDC VMware on premise in Oracle Cloud VMware Solution. Oracle Cloud VMware Solution contiene i seguenti componenti VMware:
- VMware vSphere ESXi
- VMware vSAN
- VMware vCenter
- VMware NSX-T
- VMware HCX (opzionale)
Bare Metal
Un centro dati definito da software (SDDC) Oracle Cloud VMware Solution contiene i server Bare Metal che ospita Oracle Cloud VMware Solution. Il server Bare Metal supporta applicazioni che richiedono conteggi di memorie centrali elevati, grandi quantità di memoria ed elevata larghezza di banda (ad esempio Oracle Cloud VMware Solution). Puoi distribuire Oracle Cloud VMware Solution sui server Bare Metal e configurare le virtual machine con notevoli miglioramenti a livello di prestazioni rispetto ad altri cloud pubblici e data center on premise.
Gateway del servizio
Il gateway di servizi fornisce l'accesso da una VCN ad altri servizi, come Oracle Cloud Infrastructure Object Storage. Il traffico dalla VCN al servizio Oracle viaggia sulla struttura di rete Oracle e non attraversa mai Internet.
Gateway di instradamento dinamico (DRG)
DRG è un router virtuale che fornisce un percorso per il traffico di rete privato tra VCN nella stessa area, tra una VCN e una rete esterna all'area, come una VCN in un'altra area Oracle Cloud Infrastructure, una rete in locale o una rete in un altro provider cloud.
FastConnect
Oracle Cloud Infrastructure FastConnect consente di creare facilmente una connessione dedicata e privata tra il data center e Oracle Cloud Infrastructure. FastConnect fornisce opzioni a maggiore larghezza di banda e un'esperienza di rete più affidabile se confrontata con le connessioni basate su Internet.
Storage file
Lo storage file OCI viene utilizzato durante la migrazione logica per importare il database migrato da un file system condiviso.
Storage degli oggetti
Lo storage degli oggetti OCI viene utilizzato per la migrazione logica e fisica per lo storage temporaneo durante la migrazione.

Operazioni preliminari

Prima di iniziare, controllare le versioni dei principali componenti utilizzati in questa impostazione e consultare la documentazione del prodotto per riferimento futuro.

Requisiti per la revisione

Assicurarsi che nel database di origine sia in esecuzione Oracle Database versione 19.18 Enterprise Edition o successiva.
Il database di destinazione deve essere Oracle Exadata Database Service on Dedicated Infrastructure X8 o successivo su Oracle Database versione 19.18 Enterprise Edition o successiva.
La versione di Oracle Zero Downtime Migration deve essere la versione 21.4 o successiva.
Lo storage intermedio deve includere OCI Object Storage, Oracle ZFS Storage Appliance (NAS) e OCI File Storage.

Revisione documentazione

Questo playbook sulle soluzioni descrive come migrare i carichi di lavoro del database. Per ulteriori informazioni sulla migrazione dei carichi di lavoro VMware, fare riferimento alla soluzione riportata di seguito. Le risorse aggiuntive sono utili per il contesto, i dettagli e il riferimento per la migrazione del database.

Scopri come migrare i componenti VMware del tuo carico di lavoro su Oracle Cloud VMware Solution.

Esegui la migrazione dei carichi di lavoro VMware on premise nel cloud

Esaminare le risorse di Oracle Zero Downtime Migration:

Rivedere le risorse di migrazione fisica:

Rivedere le risorse di migrazione logica:

Esaminare le risorse di Oracle Database:

Informazioni sui prodotti e i ruoli richiesti

Questa soluzione richiede i seguenti prodotti:

Oracle Cloud Infrastructure Identity and Access Management
Computazione OCI
OCI Object Storage
Storage di file OCI
Oracle Zero Downtime Migration
Oracle Exadata
Oracle Exadata Database Service on Dedicated Infrastructure

Questi sono i ruoli necessari per ogni prodotto.

Nome prodotto: Ruolo	Richiesto per...
Oracle Cloud Infrastructure Identity and Access Management: `OCI_user`	Crea token di autenticazione per la migrazione fisica Crea chiavi API per la migrazione logica
Computazione OCI: `admin`	Creare un'istanza di OCI Compute per eseguire il software Oracle Zero Downtime Migration
Storage degli oggetti OCI: `Storage Admin`	Crea bucket di Storage degli oggetti OCI per la migrazione logica e fisica
Storage di file OCI: `Storage Admin`	Creare Storage di file OCI per la migrazione logica
Oracle Zero Downtime Migration: `opc`	Creare `zdmuser` per installare ed eseguire il software Oracle Zero Downtime Migration
Oracle Zero Downtime Migration: `zdmuser`	Installare il software Oracle Zero Downtime Migration Esegui Oracle Zero Downtime Migration
Oracle Exadata: `root/sudoer user`	Attivare la condivisione del file system di rete dal dispositivo di storage collegato in rete per esportare il database per le migrazioni logiche Abilita ssh senza password dalla virtual machine Oracle Zero Downtime Migration Eseguire i comandi `sudo` per installare l'agente software Oracle Zero Downtime Migration Eseguire i comandi `sudo` per eseguire il backup o l'esportazione del database
Database Oracle Exadata: `sys/system`	Eseguire il backup dei dati utilizzando Oracle Recovery Manager (RMAN) per la migrazione fisica Eseguire Data Pump per esportare il database per la migrazione logica
Oracle Exadata Database Service on Dedicated Infrastructure: `Database Admin`	Crea database di destinazione Oracle Exadata Database Service on Dedicated Infrastructure
Oracle Exadata Database Service on Dedicated Infrastructure Nodi cluster VM: `opc`	Attivare la condivisione del file system di rete da Storage di file OCI per importare il database per le migrazioni logiche Abilita ssh senza password dalla virtual machine Oracle Zero Downtime Migration Installa agente software Oracle Zero Downtime Migration Eseguire i comandi `sudo` per ripristinare o importare il database
Oracle Exadata Database Service on Dedicated Infrastructure Database: `sys/system`	Ripristinare i dati utilizzando Oracle Recovery Manager (RMAN) per le migrazioni fisiche Eseguire Data Pump per importare il database per la migrazione logica

Scopri i prodotti, le soluzioni e i servizi Oracle per ottenere ciò di cui hai bisogno.

Informazioni sulla migrazione logica e fisica

Oracle Zero Downtime Migration supporta due tipi di migrazione del database da Oracle Exadata a Oracle Exadata Database Service on Dedicated Infrastructure: migrazione logica e migrazione fisica.

La migrazione logica utilizza una combinazione di Oracle Data Pump e Oracle GoldenGate, mentre la migrazione fisica utilizza una combinazione di Oracle Recovery Manager (RMAN) e Oracle Data Guard. Nella seguente tabella vengono descritti gli scenari in cui è necessario utilizzare una migrazione logica o fisica.

Migrazione logica	Migrazione fisica
Consigliato quando viene eseguita la migrazione di alcuni database collegabili e/o schemi.	Consigliato quando viene eseguita la migrazione di database completi. Ad esempio, i database container con tutti i database collegabili, vale a dire migrazione diretta senza modifica del codice.
È possibile eseguire la migrazione di database collegabili (PDB) e/o schemi selettivi.	I container database verranno migrati in container database e i database non di tipo container verranno migrati in database non di tipo container.
La password `Sys` nell'origine e nella destinazione può essere diversa. I nomi di database tra l'origine e la destinazione possono essere diversi.	La password `Sys` e il nome del database sia nell'origine che nella destinazione devono essere identici. DB_UNIQUE_NAME sull'origine e sulla destinazione deve essere diverso.
È possibile aggiornare i database durante la migrazione.	Impossibile aggiornare i database come parte della migrazione.

Migrazione mediante migrazione logica

In questa sezione viene descritto come eseguire una migrazione logica offline. Per la migrazione in linea, fare riferimento alla sezione Revisiona documentazione.

Prima di eseguire la migrazione, tenere presente quanto riportato di seguito.

Non è necessario cifrare il database di origine in Oracle Exadata. Oracle Zero Downtime Migration cifra il database di destinazione durante la migrazione.
I database di origine e di destinazione non devono disporre della stessa password sys, della stessa password del wallet, della stessa versione del database, del nome del database e del medesimo livello di patch.
Oracle Zero Downtime Migration consente di eseguire la migrazione di determinati database collegabili (PDB) e/o schemi ai database collegabili in Oracle Exadata Database Service on Dedicated Infrastructure.
Per le migrazioni logiche è necessario un file system condiviso. Durante la migrazione logica, Oracle Zero Downtime Migration non esporta i dati direttamente in OCI Object Storage. Nel database Exadata di origine, Oracle Zero Downtime Migration esporta i dati in un file system condiviso (file system di rete o Oracle Advanced Cluster File System). I dati esportati vengono quindi caricati nello storage degli oggetti OCI. Oracle Zero Downtime Migration, quindi sposta i dump dei dati da OCI Object Storage a OCI File Storage. Infine, Oracle Exadata Database Service on Dedicated Infrastructure può importare i dati da OCI File Storage tramite un file system di rete.
Oracle Exadata on premise può eseguire sia database a istanza singola che database RAC. Oracle Exadata Database Service on Dedicated Infrastructure esegue i database RAC. Durante la migrazione del database, Oracle Zero Downtime Migration converte i database RAC a istanza singola quando necessario.
In Oracle Exadata on premise, l'uso di Oracle Transparent Data Encryption per la cifratura dei database è facoltativo. Quando si esegue la migrazione dei database da Exadata a Oracle Exadata Database Service on Dedicated Infrastructure, il database di destinazione Oracle Exadata Database Service on Dedicated Infrastructure verrà sempre cifrato.
I passi riportati di seguito presuppongono che vi sia una connettività di rete diretta tra il data center in cui è installato Oracle Exadata e la rete cloud virtuale OCI in cui è configurata la virtual machine Oracle Exadata Database Service on Dedicated Infrastructure e Oracle Zero Downtime Migration (tramite FastConnect o IPSec VPN, come mostrato nel diagramma dell'architettura).

Nella procedura riportata di seguito viene descritto come eseguire una migrazione logica non in linea.

Nella console OCI creare un'istanza di computazione nella stessa rete VCN in cui verrà configurato il database Oracle Exadata Database Service on Dedicated Infrastructure di destinazione.
Questa istanza di computazione può essere qualsiasi forma, con almeno due OCPU e 16 GB di RAM, eseguendo il sistema operativo Oracle Linux 7.9. Questa virtual machine verrà utilizzata per eseguire il software Oracle Zero Downtime Migration.
Seguire la documentazione di installazione di Oracle Zero Downtime Migration nella sezione Rivedi documentazione per scaricare e installare il software Oracle Zero Downtime Migration 21.4 nell'istanza di computazione OCI.
Eseguire il software Oracle Zero Downtime Migration come zdmuser.
Eseguire il login come zdmuser all'istanza di computazione in cui è in esecuzione il software Oracle Zero Downtime Migration e generare una coppia di chiavi ssh. Abilitare l'Ssh senza password dall'account zdmuser a tutti i nodi nel database Exadata di origine (root, privilege-sudoer user) e a tutti i nodi cluster VM nell'account opc user del database Oracle Exadata Database Service on Dedicated Infrastructure di destinazione.
Assicurarsi che la VM Oracle Zero Downtime Migration possa comunicare con gli host del database di origine utilizzando il nome host e l'indirizzo IP. Verificare quanto riportato di seguito.
- Modificare il resolver DNS VCN o il file /etc/hosts nella VM Oracle Zero Downtime Migration, se necessario.
- Verificare che esista una regola di sicurezza che consenta alla VM Oracle Zero Downtime Migration di connettersi al database di origine sulla porta 1521 e sulla porta ssh 22 del listener predefinito.
- Assicurarsi che la VM Oracle Zero Downtime Migration possa raggiungere gli host Oracle Exadata Database Service on Dedicated Infrastructure di destinazione sulla porta listener 1521 e sulla porta ssh 22 predefinite.
In Oracle ZFS Storage Appliance o nel dispositivo di storage collegato alla rete, creare una condivisione del file system di rete da utilizzare come segnaposto per i dump dei dati del database durante l'avanzamento della migrazione.
Eseguire il MOUNT della condivisione del file system di rete su tutti i nodi del database Exadata.
Assicurarsi che tutti gli utenti dispongano delle autorizzazioni di lettura, scrittura, esecuzione (rwx). Prendere nota del punto di attivazione.
Nella console OCI creare uno Storage di file OCI.
Prendere nota della destinazione di accesso, dell'esportazione e dell'indirizzo IP. Per impostazione predefinita, l'indirizzo IP si trova nella rete di backup di Oracle Exadata Database Service on Dedicated Infrastructure.
Utilizzare l'indirizzo IP ed esportare dal passo 7 per eseguire il MOUNT di questo storage di file tramite il file system di rete su tutti i nodi del cluster VM Oracle Exadata Database Service on Dedicated Infrastructure.
Assicurarsi che la rete cloud virtuale includa un criterio di sicurezza che consenta il protocollo del file system di rete sulla rete di backup Oracle Exadata Database Service on Dedicated Infrastructure. Prendere nota del punto di accesso.
Crea un database Oracle Exadata Database Service on Dedicated Infrastructure di destinazione utilizzando la console OCI o l'API REST. Configurare il database come indicato di seguito.
- Il nuovo database di destinazione può avere un nome diverso da quello del database di origine.
- Il nuovo database può essere una versione più recente del database di origine.
- Specificare una password per l'utente admin. Prendere nota della password.
- Non selezionare una destinazione di backup o abilitare i backup automatici durante la creazione del database. Queste impostazioni possono essere abilitate dopo la migrazione del database.
Prendere nota dell'OCID del database dopo la creazione del database.
Nella console OCI, creare un bucket dello storage degli oggetti OCI se non ne esiste già uno.
Prendi nota dell'URL Swift, dello spazio di nomi dello storage degli oggetti e del nome del bucket.
Utilizzare la console OCI per creare una chiave API per l'utente OCI che possiede il database di destinazione Oracle Exadata Database Service on Dedicated Infrastructure e dispone anche delle autorizzazioni per caricare i dati nel bucket di OCI Object Storage creato nel passo 10.
Prendere nota dell'OCID utente, dell'OCID della tenancy, dell'impronta digitale e dell'area OCI. Salvare le chiavi private e pubbliche corrispondenti nei file PEM. Questa chiave API verrà utilizzata da Oracle Zero Downtime Migration per connettersi a OCI per ottenere le informazioni sul database di destinazione durante la migrazione del database e per caricare i dump dei dati in OCI Object Storage.
Copiare i file PEM dal passo precedente nella VM Oracle Zero Downtime Migration.
Eseguire il login come utente sys al database Exadata di origine per assicurarsi che il parametro Streams_Pool_Size sia impostato almeno su 2G, ad esempio:
```
SQL>show parameter streams_pool_size;
SQL>alter system set streams_pool_size=2G scope=both SID=’*’;                  
```
Utilizzare il modello di file di risposta della migrazione logica di Oracle Zero Downtime Migration incluso in Migrazione senza tempi di inattività per creare un file di risposta per la migrazione. Di seguito sono riportati i parametri chiave.
- TARGETDATABASE_OCID: OCID del database di destinazione Oracle Exadata Database Service on Dedicated Infrastructure.
- MIGRATION_METHOD: OFFLINE_LOGICAL
- DATA_TRANSFER_MEDIUM: OSS
- TARGETDATABASE_ADMINUSERNAME: system
- SOURCEDATABASE_ADMINUSERNAME: system
- SOURCEDATABASE_CONNECTIONDETAILS_HOST: IP/nome host del primo nodo nel database Exadata di origine.
- SOURCEDATABASE_CONNECTIONDETAILS_PORT: 1521
- SOURCEDATABASE_CONNECTIONDETAILS_SERVICENAME: nome del servizio del database PDB di origine o non di tipo container (non CDB). Utilizzare lsnrctl per cercare.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_TENANTID: OCID della tenancy dal passo 11.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_USERID: OCID utente dal passo 11.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_FINGERPRINT: impronta digitale dal passo 11.
- OCIAUTHENTICATIONDETAILS_PRIVATEKEYFILE: percorso del file del file PEM di chiave privata nel server Oracle Zero Downtime Migration dal passo 12.
- OCIAUTHENTICATIONDETAILS_REGIONID: ID dell'area OCI per l'utente OCI dal passo 11.
- TARGETDATABASE_CONNECTIONDETAILS_PORT: 1521
- TARGETDATABASE_CONNECTIONDETAILS_SERVICENAME: nome del servizio per il pluggable database di destinazione nel database di destinazione. Utilizzare lsnrctl per cercare.
- SOURCECONTAINERDATABASE_ADMINUSERNAME: system
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_HOST: IP/nome host del primo nodo nel database Exadata di origine.
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_PORT: 1521
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_SERVICENAME: nome del servizio per il container database di origine nel database Exadata. Utilizzare lsnrctl per trovare).
- DATAPUMPSETTINGS_JOBMODE: SCHEMA
- DATAPUMPSETTINGS_FIXINVALIDOBJECTS: TRUE
- DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_NAME: mig
- DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_PATH: punto di attivazione del file system di rete dal passo 6.
- DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_NAME: mig.
- DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_PATH: punto di attivazione del file system di rete dal passo 8.
- DATAPUMPSETTINGS_CREATEAUTHTOKEN: TRUE
- DATAPUMPSETTINGS_DATAPUMPPARAMETERS_IMPORTPARALLELISMDEGREE: 4
- DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXPORTPARALLELISMDEGREE: 4
- DATAPUMPSETTINGS_DATABUCKET_NAMESPACE: spazio di nomi Storage degli oggetti OCI dal passo 10.
- DATAPUMPSETTINGS_DATABUCKET_BUCKETNAME: nome bucket dello storage degli oggetti OCI dal passo 10.
- TABLESPACEDETAILS_AUTOCREATE: TRUE
- TABLESPACEDETAILS_USEBIGFILE: TRUE
- TABLESPACEDETAILS_EXTENTSIZEMB: 512
- EXCLUDEOBJECTS-1: owner:PDBADMIN
Eseguire un job di migrazione a esecuzione manuale Oracle Zero Downtime Migration (-eval), per convalidare tutti i prerequisiti per la migrazione sono possibili. Questa operazione esegue lo strumento CPAT (Cloud Pre-Migration Advisor Tool) per convalidare il database di origine è adatto per la migrazione a Oracle Exadata Database Service on Dedicated Infrastructure utilizzando la migrazione logica di Oracle Zero Downtime Migration. Risolvere i problemi segnalati da CPAT prima di continuare. Ad esempio:
```
zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user:root_or_sudoer_user \
-srcarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_14 \
-eval
```
Questo comando richiede la password dell'utente sys dei database di origine e di destinazione.

Dopo la corretta migrazione dell'esecuzione manuale, procedere al passo successivo.

Una volta completata la migrazione a esecuzione manuale, eseguire il job Oracle Zero Downtime Migration. Ad esempio:

zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user:root_or_sudoer_user \
-srcarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_14

Questo comando richiede la password dell'utente sys dei database di origine e di destinazione.

Migrazione mediante migrazione fisica

In questa sezione viene descritto come eseguire una migrazione fisica offline. Per la migrazione in linea, fare riferimento alla sezione Revisiona documentazione.

Prima di eseguire la migrazione fisica, tenere presente quanto riportato di seguito.

In Oracle Database 19.16 è disponibile un nuovo parametro per la gestione della cifratura delle tablespace. Questo parametro può causare conflitti per le migrazioni fisiche. Per ulteriori informazioni, vedere Gestione della cifratura della tablespace nella sezione Rivedi documentazione.
Oracle Exadata on premise può eseguire sia database a istanza singola che database RAC. Oracle Exadata Database Service on Dedicated Infrastructure esegue i database RAC. Durante la migrazione del database, Oracle Zero Downtime Migration converte i database RAC a istanza singola quando necessario.
È necessario definire un wallet TDE (Transparent Data Encryption) nel database di origine prima della migrazione, anche se il database di origine non è cifrato.
In Oracle Exadata on premise, l'uso di Oracle Transparent Data Encryption per la cifratura dei database è facoltativo. Quando si esegue la migrazione dei database da Exadata a Oracle Exadata Database Service on Dedicated Infrastructure, il database di destinazione Oracle Exadata Database Service on Dedicated Infrastructure verrà sempre cifrato.
I passi riportati di seguito presuppongono che vi sia una connettività di rete diretta tra il data center in cui è installato Exadata e la rete cloud virtuale OCI in cui è configurata la virtual machine Oracle Exadata Database Service on Dedicated Infrastructure e Oracle Zero Downtime Migration (tramite FastConnect o IPSec VPN, come mostrato nel diagramma dell'architettura).
Non è necessario cifrare il database di origine in Oracle Exadata. Oracle Zero Downtime Migration cifra il database di destinazione durante la migrazione.
La password sys, la password del wallet, la versione del database e il livello di patch nei database di origine e di destinazione devono essere uguali.
Oracle Zero Downtime Migration eseguirà la migrazione del container database (CDB) in CDB e non CDB in un CDB non.
Oracle Zero Downtime Migration utilizza Oracle Database Backup Cloud Service per eseguire il backup del database Exadata di origine nello storage degli oggetti OCI. Oracle Zero Downtime Migration, quindi ripristina il database di destinazione da questo backup.

Nella procedura riportata di seguito viene descritto come eseguire una migrazione fisica offline.

Nella console OCI creare un'istanza di computazione nella stessa subnet in cui verrà configurato il database di destinazione.
Questa istanza di computazione può essere qualsiasi forma, con almeno due OCPU e 16 GB di RAM, eseguendo il sistema operativo Oracle Linux 7.9. Questa virtual machine verrà utilizzata per eseguire il software Oracle Zero Downtime Migration.
Seguire la documentazione di installazione di Oracle Zero Downtime Migration nella sezione Rivedi documentazione per scaricare e installare il software Oracle Zero Downtime Migration 21.4 nell'istanza di computazione OCI.
Eseguire il software Oracle Zero Downtime Migration come zdmuser.
Eseguire il login come zdmuser all'istanza di computazione che esegue il software Oracle Zero Downtime Migration e generare una coppia di chiavi ssh. Abilitare l'Ssh senza password dall'account zdmuser a tutti i nodi nel database Exadata di origine (root, privilege-sudoer user) e a tutti i nodi cluster VM nell'account opc user del database di destinazione.
Assicurarsi che la VM Oracle Zero Downtime Migration possa comunicare con gli host del database di origine utilizzando il nome host e l'indirizzo IP. Verificare quanto riportato di seguito.
- Modificare il resolver DNS VCN o il file /etc/hosts nella VM Oracle Zero Downtime Migration, se necessario.
- Verificare che esista una regola di sicurezza che consenta alla VM Oracle Zero Downtime Migration di connettersi al database di origine sulla porta 1521 e sulla porta ssh 22 del listener predefinito.
- Assicurarsi che la VM Oracle Zero Downtime Migration sia in grado di raggiungere gli host del database di destinazione sulla porta predefinita del listener 1521 e sulla porta ssh 22.
Nella console OCI, creare un bucket dello storage degli oggetti OCI se non ne esiste già uno.
Prendi nota dell'URL Swift, dello spazio di nomi dello storage degli oggetti e del nome del bucket.
Nella console OCI creare un token di autenticazione per OCI_user caricando i dati nel bucket dello storage degli oggetti OCI.
Il token non verrà visualizzato di nuovo.
Assicurati che i criteri di sicurezza consentano a OCI_user di caricare i dati nel bucket dello storage degli oggetti OCI.
Crea un database di destinazione di Oracle Exadata Database Service on Dedicated Infrastructure utilizzando la GUI OCI o l'API REST. Configurare il database di destinazione come indicato di seguito.
- I database di destinazione e di origine devono avere gli stessi nomi, ma DB_UNIQUE_NAME diverso.
- La password sys, la password del wallet, la versione del database, il livello di patch e la versione del file del fuso orario nei database di origine e di destinazione devono essere uguali.
- Non selezionare una destinazione di backup o abilitare i backup automatici. Queste impostazioni possono essere abilitate dopo la migrazione del database.
Verificare che il database di origine sia configurato in modalità log di archiviazione. Se il log di archivio non è abilitato, vedere Abilita modalità log di archivio di seguito.
Se il database di origine non è cifrato, vedere Configura un keystore TDE (Transparent Data Encryption) di seguito. Non è necessario cifrare i dati, è necessario solo il keystore TDE per la migrazione fisica. Assicurarsi che la password del keystore (wallet) sia uguale alla password di sistema/wallet utilizzata per creare il database di destinazione in Oracle Exadata Database Service on Dedicated Infrastructure.
Creare un file di risposta per Oracle Zero Downtime Migration per eseguire la migrazione. I parametri principali includono:
- TGT_DB_UNIQUE_NAME: nome univoco del database per il database di destinazione Oracle Exadata Database Service on Dedicated Infrastructure.
- MIGRATION_METHOD: OFFLINE_PHYSICAL o ONLINE_PHYSICAL.
- DATA_TRANSFER_MEDIUM: OSS
- PLATFORM_TYPE: EXACS
- HOST: l'URL Swift per lo spazio di nomi OCI Object Storage dal passo 5 nel formato: https://swiftobjectstorage.<region>.oraclecloud.com/v1/<namespace>>. Ad esempio:
```
https://switfobjectstorage.us-phoenix-1.oraclecloud.com/v1/axwytvijqqld
```
- OPC_CONTAINER: nome bucket dello storage degli oggetti OCI dal passo 4.
- SHUTDOWN_SRC: TRUE

Eseguire un job di migrazione a esecuzione manuale Oracle Zero Downtime Migration (-eval), per convalidare tutti i prerequisiti per la migrazione sono possibili. Ad esempio:

zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user: root_or_sudoer_user \
-srcarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_10 \
-backupuser “OCI_user_id_for_user_allowed_to_upload_data_to_OCI_object_storage_bucket”
-eval

Questo comando richiede due password. La prima password è la password sys per il database di origine. La seconda password è la password OCI_user per l'utente che carica i dati nel bucket dello storage degli oggetti OCI. Non immettere qui la password utente, immettere invece il token di autenticazione dal passo 6.

Dopo un'esecuzione manuale riuscita, procedere al passo successivo.

Eseguire il job Oracle Zero Downtime Migration. Ad esempio:

zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user: root_or_sudoer_user \
-srcarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_10 \
-backupuser “OCI_user_id_for_user_allowed_to_upload_data_to_OCI_object_storage_bucket”

Migrazione fisica offline completata.

Abilita modalità log di archiviazione

La modalità del log di archivio deve essere abilitata nel database di origine per le migrazioni fisiche di Oracle Zero Downtime Migration. In questi passi viene descritto come configurare la modalità Archivelog nel database di origine.

Convalida che il database di origine non sia configurato in modalità Log di archivio.
```
SQL> select log_mode from v$database;
LOG_MODE
------------
NOARCHIVELOG
```

Configurare la destinazione dell'archivio di log del database di origine. Poiché questa configurazione riguarda un database in esecuzione in Exadata, la destinazione del log di archivio deve essere il gruppo di dischi ASM RECO di Oracle.

SQL> alter system set log_archive_dest_1='LOCATION=+RECOC1' scope=both SID='*';
System altered.
SQL> select destination,STATUS from v$archive_dest where statuS='VALID';
DESTINATION
--------------------------------------------------------------------------------
STATUS
---------
+RECOC1
VALID

Chiudere il database.
```
$ srvctl stop database -d db_name
```
Avviare l'attivazione del database sul primo nodo.
```
SQL> startup mount;
ORACLE instance started.
```
Abilita la modalità Archivelog.
```
alter database archivelog;
```
Aprire il database.
```
alter database open;
```

Verificare che il database sia in modalità Archivelog.

SQL> select log_mode from v$database;
LOG_MODE
------------
ARCHIVELOG
SQL> select destination,STATUS from v$archive_dest where status='VALID';
DESTINATION
--------------------------------------------------------------------------------
STATUS
---------
+RECOC1
VALID

Riavviare il database sul secondo nodo.

$ srvctl start instance -d db_name -n hostname_node2

Verificare che i database collegabili siano in modalità di apertura, lettura e scrittura su entrambi i nodi. Se i database collegabili non sono aperti, aprire i database collegabili su entrambi i nodi e salvare lo stato.
```
SQL> Alter pluggabale database pdb_name open instances=all;
SQL>Alter pluggable database pdb_name save state instances=all;
```

Configurare un keystore TDE (Transparent Data Encryption)

Le migrazioni fisiche di Oracle Zero Downtime Migration richiedono un keystore/wallet di cifratura TDE auto_login (anche se il database di origine non è cifrato). Questo keystore deve essere configurato con la stessa password del keystore del database di destinazione. In questi passi viene descritto come configurare un keystore nel database di origine.

Controllare se esiste una posizione keystore predefinita configurata per il database.

SQL> select * from v$encryption_wallet;
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
/u01/app/oracle/admin/db_name/wallet
NOT_AVAILABLE UNKNOWN SINGLE NONE UNDEFINED
1
SQL>

Questo output mostra che non è configurato alcun keystore o wallet.

Impostare la variabile TNS_ADMIN per l'utente oracle su entrambi i nodi Exadata.
```
$ORACLE_HOME/network/admin/db_name
```
Creare una directory in cui memorizzare il file sqlnet.ora su entrambi i nodi Exadata a cui punta TNS_ADMIN.
```
mkdir -p $ORACLE_HOME/network/admin/db_name
```

Creare il file sqlnet.ora nella directory a cui punta TNS_ADMIN con il contenuto seguente in entrambi i nodi Exadata.

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)
 (METHOD_DATA=(DIRECTORY=/u01/app/oracle/admin/db_name/wallet)))

Creare una directory per memorizzare il keystore o il wallet nella posizione a cui punta sqlnet.ora su entrambi i nodi Exadata.
```
$mkdir -p $/u01/app/oracle/admin/db_name/wallet
```
Nel primo nodo creare il keystore protetto con una password.
È necessario configurare anche il keystore del database di destinazione con questa password.
```
SQL>administer key management create keystore '/u01/app/oracle/admin/db_name/wallet' identified by keystore_password;
```
Nel primo nodo aprire il keystore.
Se il database di origine è un database non CDB, rimuovere container = ALL.
```
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password container = ALL;
```
Creare un backup per il keystore.
Se il database di origine è un database non CDB, rimuovere container = ALL.
```
SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY keystore_password with backup container = ALL;
```

Verificare che il keystore sia stato creato e di cui sia stato eseguito il backup.

SQL> SELECT * FROM v$encryption_keys;
Snip…
ACTIVATING_PDBNAME
--------------------------------------------------------------------------------
ACTIVATING_PDBID ACTIVATING_PDBUID ACTIVATING_PDBGUID CON_ID
---------------- ----------------- -------------------------------- ----------
ATOlrcGaa0/iv/dFeRSkNSIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--------------------------------------------------------------------------------
ACTIVATING_PDBID ACTIVATING_PDBUID ACTIVATING_PDBGUID CON_ID
---------------- ----------------- -------------------------------- ----------
db_name
ACTIVATING_PDBID ACTIVATING_PDBUID ACTIVATING_PDBGUID CON_ID
---------------- ----------------- -------------------------------- ----------
1 86B637B62FDF7A65E053F706E80A27CA
Snip…

Creare un keystore auto_login dal keystore creato al passo 7.

SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE '/u01/app/oracle/admin/db_name/wallet' IDENTIFIED BY keystore_password ;

Chiudere il keystore dal passo 7.

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY keystore_password;

Verificare che il keystore auto_login sia ancora aperto.

SQL> SELECT * FROM v$encryption_wallet;
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
/u01/app/oracle/admin/db_name/wallet
OPEN AUTOLOGIN SINGLE NONE NO

Creare i file wallet dal nodo 1 al nodo 2.

cd /u01/app/oracle/admin/db_name/wallet.
scp * node_2:/u01/app/oracle/admin/db_name/wallet

Riavviare il database su entrambi i nodi Exadata.

$ srvctl stop database -d db_name
$ srvctl start database -d db_name
$ srvctl status database -d db_name
Instance db_name1 is running on node node_1
Instance db_name2 is running on node node_2

Verificare che il wallet auto_login sia aperto su entrambi i nodi.

SQL> SELECT * FROM v$encryption_wallet;
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
/u01/app/oracle/admin/db_name/wallet/
OPEN AUTOLOGIN SINGLE NONE NO
1
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
OPEN AUTOLOGIN SINGLE UNITED NO
2
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
OPEN_NO_MASTER_KEY AUTOLOGIN SINGLE UNITED UNDEFINED
3
SQL>

Verificare che i database collegabili siano in modalità di apertura, lettura e scrittura su entrambi i nodi. Se i database collegabili non sono aperti, aprire i database collegabili su entrambi i nodi e salvare lo stato.
```
SQL> Alter pluggabale database pdb_name open instances=all;
SQL>Alter pluggable database pdb_name save state instances=all;
```