Documentazione di Oracle Cloud Infrastructure

Panoramica di Exadata Cloud@Customer Gen1 per l'upgrade cloud non in loco a Oracle Exadata Database Service on Cloud@Customer Gen2 Infrastructure

Gen1 è la prima generazione di Exadata Database Service on Cloud@Customer, che viene distribuita insieme a Gen1 Oracle Cloud At Customer (OCC) come piano di controllo distribuito nel data center del cliente. Oracle Exadata Database Service on Cloud@Customer Gen2 è gestito dal piano di controllo Oracle Cloud Infrastructure (OCI), che viene eseguito nel cloud pubblico OCI.

Aggiornamento cloud fuori luogo a Exadata Database Service on Cloud@Customer Gen2 Infrastructure: se si esegue Exadata Cloud@Customer Gen1 sull'infrastruttura X6 o X7, con questa offerta Oracle sostituirà l'infrastruttura Gen1 X6 o X7 con la nuova infrastruttura Gen2 Cloud@Customer Cloud@Customer e fornirà le istruzioni per utilizzare Oracle Zero Downtime Migration (ZDM) per eseguire la migrazione dei database sulla piattaforma Exadata Cloud@Customer Gen1 alla piattaforma Exadata Cloud@Customer Gen2. La sostituzione dell'infrastruttura Exadata Cloud@Customer Gen1 X6 o X7 e la migrazione dei database alla piattaforma Exadata Cloud@Customer Gen2 sono chiamate upgrade cloud non in loco.

Argomento padre: guide esplicative

Ambito per l'upgrade cloud di Exadata Cloud@Customer da Gen1 a Gen2 non in loco

  • Le forme di sistema Exadata Cloud@Customer X6 e X7 sono idonee per l'upgrade out-of-place.
  • I database su Exadata Cloud@Customer Gen1 che partecipano a una configurazione Data Guard sono supportati dalla migrazione. In questo caso, è necessario eseguire la migrazione del database primario a Exadata Cloud@Customer Gen2 utilizzando la procedura standard. Una volta eseguita la migrazione, la configurazione Data Guard deve essere impostata sul lato Gen2 di Exadata Cloud@Customer utilizzando la procedura Gen2 standard.

  • L'upgrade da Exadata Cloud@Customer Gen1 a Gen2 viene eseguito solo quando le versioni software sono compatibili nei sistemi di origine e di destinazione.

    • Software Oracle Database: l'origine e la destinazione devono avere la stessa versione principale. Ad esempio, sia l'origine che la destinazione devono essere nella versione 19c. Tuttavia, la destinazione può avere un livello di patch superiore rispetto all'origine. Ad esempio, le versioni delle patch possono essere 19.3 per l'origine e 19.8 per la destinazione. L'equivalenza corrispondente per la versione 12.2 è che sia l'origine che la destinazione devono trovarsi nella versione 12.2.0.1 del software Oracle Database, ma i livelli di patch possono essere 2019JulyRU nell'origine e 2020OctRU nella destinazione.
    • Da database non di tipo container (CDB) a non CDB.
    • Distribuzione multi-tenant (CDB/PDB) in distribuzione multi-tenant (CDB/PDB).
    • Oracle Database a istanza singola: dopo la migrazione, l'origine del database a istanza singola verrà convertita nel database Oracle Real Application Clusters (Oracle RAC) sulla destinazione.
  • Le differenze consentite nelle versioni software includono:
    • Oracle Grid Infrastructure
    • Software Exadata
    • Sistema operativo VM guest
    • DBaaS strumenti
  • I database Oracle creati su Exadata Cloud@Customer Gen1 utilizzando gli strumenti backend, dbaasapi e dbaascli sono supportati, oltre ai database Oracle creati utilizzando la console Gen1.
  • Sono supportate tutte le versioni supportate di Oracle Database su Exadata Cloud@Customer Gen1 e verrà eseguita la migrazione alla stessa versione principale nella destinazione. L'ambiente Gen2 si troverà nella versione più recente supportata di Exadata Cloud@Customer Gen2 per il sistema operativo della VM guest e Oracle Grid Infrastructure.

Tenere presente che quanto segue non rientra nell'ambito dell'upgrade cloud out-of-place al nuovo hardware Gen2:

  • La distribuzione di Exadata Cloud@Customer Gen1 utilizzando le funzioni Exadata Cloud@Customer Gen1 non ancora disponibili su Gen2 non prevede di utilizzare le procedure di upgrade finché non sarà disponibile la funzione o un equivalente pertinente su Gen2.
  • Solo l'upgrade di Exadata Cloud@Customer è incluso nell'ambito della procedura qui. L'aggiornamento o la migrazione di OCC non rientra nell'ambito.
  • È possibile invertire l'aggiornamento fino a quando l'hardware principale e secondario non si trovano sul sito. La perdita di dati è possibile a seconda dell'utilizzo dell'applicazione e del tempo di cutover. Dopo aver rispedito l'hardware Exadata Cloud@Customer Gen1 a Oracle, non è possibile annullare l'upgrade e non è possibile tornare a Exadata Cloud@Customer Gen1.

Hardware e software necessari per l'upgrade cloud non in loco alla nuova infrastruttura Oracle Exadata Database Service on Cloud@Customer Gen2

Consulta questa lista di controllo per prepararti all'upgrade cloud non in loco alla nuova infrastruttura Gen2:

  • Imposta ambiente Exadata Cloud@Customer Gen2

    Una distribuzione Gen2 di Exadata Cloud@Customer di base funzionante è un prerequisito per avviare qualsiasi upgrade non in loco di Exadata Cloud@Customer Gen1 a Gen2.

    Per ulteriori informazioni su come impostare Gen2 Exadata Cloud@Customer, vedere Preparazione di Exadata Cloud@Customer.

  • Imposta l'hardware per eseguire la migrazione dei database Oracle utilizzando Oracle Zero Downtime Migration (ZDM). Per ulteriori informazioni, vedere Preparare un host per l'installazione del software di migrazione senza tempi di inattività

  • Configura rete
    • Fornire il percorso di accesso alla rete dai server Gen1 di Exadata Cloud@Customer e dai server Gen2 ai server ZDM utilizzati per l'upgrade.
    • Fornire l'accesso alla rete e l'accesso SSH dal server ZDM alla rispettiva infrastruttura Exadata Cloud@Customer.
    • Per qualsiasi accesso client ai database di destinazione, assicurarsi che un percorso di rete sia disponibile dall'host client ai nuovi database distribuiti di Exadata Cloud@Customer Gen2.
  • Software
    • L'upgrade richiederà versioni minime dello stack software, quindi prima dell'upgrade, installare la versione appropriata di Oracle Grid Infrastructure nell'infrastruttura Exadata Cloud@Customer Gen2 di destinazione.
    • Le versioni di Oracle Database supportate su Exadata Cloud@Customer Gen1 continueranno a essere supportate. Nell'infrastruttura Gen2 di destinazione, installare le versioni appropriate del software Oracle Database e le patch singole esistenti nel database di origine.
    • Completare tutti i requisiti per i server ZDM in termini di installazione, configurazione, accesso alla rete e accesso SSH.
  • Sicurezza
    • Exadata Cloud@Customer Gen2 non utilizza Oracle Advanced Support Gateway Security (OASG), pertanto non può richiedere i log OASG.
  • Assicurarsi che il backup automatico non sia configurato nella destinazione Gen2 prima della migrazione.

Uso di Oracle Zero Downtime Migration (ZDM) per eseguire la migrazione dei database Oracle

Utilizzare ZDM per eseguire la migrazione dei database Oracle dall'infrastruttura Gen1 Exadata Cloud@Customer a Oracle Exadata Database Service on Cloud@Customer Gen2.

Per acquisire familiarità con le funzioni di ZDM, vedere Setting Up Zero Downtime Migration Software. Come primo passo, scaricare, installare e configurare ZDM sull'host identificato per il server ZDM.

La migrazione senza tempi di inattività supporta sia la migrazione in linea che quella offline (backup e ripristino). Per l'upgrade di Exadata Cloud@Customer da Gen1 a Gen2, si consiglia di utilizzare la migrazione fisica ZDM. In particolare, si consiglia di utilizzare la migrazione online con trasferimento dati diretto (migrazione fisica online (MIGRATION_METHOD=ONLINE_PHYSICAL) utilizzando il trasferimento dati diretto (DATA_TRANSFER_MEDIUM=DIRECT). La migrazione online con trasferimento diretto dei dati è disponibile con Zero Downtime Migration 21.2 e supporta il trasferimento diretto dei dati per la metodologia di migrazione fisica. Questa nuova funzione consente agli utenti di evitare di utilizzare un'area di memorizzazione intermedia per i backup (in genere NFS o OCI Object Storage). ZDM utilizza la duplicazione attiva del database (per i database 11.2) o il ripristino dal servizio (per oltre 12 database). È possibile utilizzare questo metodo per eseguire la migrazione dei database Exadata Cloud@Customer Gen1 a Exadata Cloud@Customer Gen2. Di seguito sono riportati alcuni esempi di file di riga di comando e di risposta.

Per ulteriori informazioni, fare riferimento agli argomenti sotto riportati.

  • Introduzione alla migrazione senza tempo di inattività
  • Preparazione alla migrazione del database
  • Migrazione del database senza tempi di inattività

Esempio 5-4 duplicato attivo

zdmcli migrate database -sourcedb z19tgt1 -sourcenode scaqae03client01vm06 -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/giusr/.ssh/id_gen1vm -srcarg3 sudo_location:/usr/bin/sudo -targetnode tgt1 -rsp /home/giusr/activeduplicate_zdm_online_19c.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/giusr/.ssh/dbaas_sshkey.priv -tgtarg3 sudo_location:/usr/bin/sudo -schedule NOW -tdekeystorepasswd
ZDM_GET_SRC_INFO .............. COMPLETED
ZDM_GET_TGT_INFO .............. COMPLETED
ZDM_PRECHECKS_SRC ............. COMPLETED
ZDM_PRECHECKS_TGT ............. COMPLETED
ZDM_SETUP_SRC ................. COMPLETED
ZDM_SETUP_TGT ................. COMPLETED
ZDM_PREUSERACTIONS ............ COMPLETED
ZDM_PREUSERACTIONS_TGT ........ COMPLETED
ZDM_VALIDATE_SRC .............. COMPLETED
ZDM_VALIDATE_TGT .............. COMPLETED
ZDM_DISCOVER_SRC .............. COMPLETED
ZDM_COPYFILES ................. COMPLETED
ZDM_PREPARE_TGT ............... COMPLETED
ZDM_SETUP_TDE_TGT ............. COMPLETED
ZDM_DUPLICATE_TGT ............. COMPLETED
ZDM_FINALIZE_TGT .............. COMPLETED
ZDM_CONFIGURE_DG_SRC .......... COMPLETED
ZDM_SWITCHOVER_SRC ............ COMPLETED
ZDM_SWITCHOVER_TGT ............ COMPLETED
ZDM_POST_DATABASE_OPEN_TGT .... COMPLETED
ZDM_DATAPATCH_TGT ............. COMPLETED
ZDM_MANIFEST_TO_CLOUD ......... COMPLETED
ZDM_POST_MIGRATE_TGT .......... COMPLETED
ZDM_POSTUSERACTIONS ........... COMPLETED
ZDM_POSTUSERACTIONS_TGT ....... COMPLETED
ZDM_CLEANUP_SRC ............... COMPLETED
ZDM_CLEANUP_TGT ............... COMPLETED

File di risposta duplicato attivo di esempio 5-5

TGT_DB_UNIQUE_NAME=z19tgt1_uniq2
MIGRATION_METHOD=ONLINE_PHYSICAL
DATA_TRANSFER_MEDIUM=DIRECT
PLATFORM_TYPE=EXACC
SRC_HTTP_PROXY_URL=
SRC_HTTP_PROXY_PORT=
SRC_CONFIG_LOCATION=
SRC_BASTION_HOST_IP=
SRC_BASTION_PORT=
SRC_BASTION_USER=
SRC_BASTION_IDENTITY_FILE=
SRC_HOST_IP=
SRC_TIMEZONE=
SRC_OSS_PROXY_HOST=
SRC_OSS_PROXY_PORT=
SRC_SSH_RETRY_TIMEOUT=
SRC_PDB_NAME=
SRC_DB_LISTENER_PORT=
TGT_HTTP_PROXY_URL=
TGT_HTTP_PROXY_PORT=
TGT_CONFIG_LOCATION=
TGT_BASTION_HOST_IP=
TGT_BASTION_PORT=
TGT_BASTION_USER=
TGT_BASTION_IDENTITY_FILE=
TGT_HOST_IP=
TGT_SSH_TUNNEL_PORT=
TGT_SSH_RETRY_TIMEOUT=
TGT_OSS_PROXY_HOST=
TGT_OSS_PROXY_PORT=
TGT_DATADG=
TGT_REDODG=
TGT_RECODG=
TGT_DATAACFS=
TGT_REDOACFS=
TGT_RECOACFS=
BACKUP_PATH=
HOST=
OPC_CONTAINER=
SRC_ZDLRA_WALLET_LOC=
TGT_ZDLRA_WALLET_LOC=
ZDLRA_CRED_ALIAS=
NONCDBTOPDB_CONVERSION=FALSE
NONCDBTOPDB_SWITCHOVER=TRUE
SKIP_FALLBACK=TRUE
TGT_RETAIN_DB_UNIQUE_NAME=
TGT_SKIP_DATAPATCH=FALSE
MAX_DATAPATCH_DURATION_MINS=
DATAPATCH_WITH_ONE_INSTANCE_RUNNING=
SHUTDOWN_SRC=
SKIP_SRC_SERVICE_RETENTION=
SRC_RMAN_CHANNELS=6
TGT_RMAN_CHANNELS=16
ZDM_LOG_OSS_PAR_URL=
ZDM_BACKUP_FULL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_INCREMENTAL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_DIFFERENTIAL_SRC_MONITORING_INTERVAL=10
ZDM_CLONE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RESTORE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RECOVER_TGT_MONITORING_INTERVAL=10
ZDM_BACKUP_RETENTION_WINDOW=
ZDM_BACKUP_TAG=
ZDM_USE_EXISTING_BACKUP=
ZDM_OPC_RETRY_WAIT_TIME=
ZDM_OPC_RETRY_COUNT=
ZDM_SRC_TNS_ADMIN=
ZDM_CURL_LOCATION=
ZDM_USE_EXISTING_UNDO_SIZE=
ZDM_SKIP_DG_CONFIG_CLEANUP=
ZDM_RMAN_COMPRESSION_ALGORITHM=LOW
ZDM_SRC_DB_RESTORE_SERVICE_NAME=
ZDM_RMAN_DIRECT_METHOD=ACTIVE_DUPLICATE

Esempio 5-6 Ripristino da servizio

zdmcli migrate database -sourcedb z12tgt1s -sourcenode scaqae03client01vm06 -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/giusr/.ssh/id_gen1vm -srcarg3 sudo_location:/usr/bin/sudo -targetnode tgt1 -rsp /home/giusr/dir_zdm_online_121_sidb.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/giusr/.ssh/dbaas_sshkey.priv-tgtarg3 sudo_location:/usr/bin/sudo -schedule NOW -tdekeystorepasswd"
ZDM_GET_SRC_INFO .............. COMPLETED
ZDM_GET_TGT_INFO .............. COMPLETED
ZDM_PRECHECKS_SRC ............. COMPLETED
ZDM_PRECHECKS_TGT ............. COMPLETED
ZDM_SETUP_SRC ................. COMPLETED
ZDM_SETUP_TGT ................. COMPLETED
ZDM_PREUSERACTIONS ............ COMPLETED
ZDM_PREUSERACTIONS_TGT ........ COMPLETED
ZDM_VALIDATE_SRC .............. COMPLETED
ZDM_VALIDATE_TGT .............. COMPLETED
ZDM_DISCOVER_SRC .............. COMPLETED
ZDM_COPYFILES ................. COMPLETED
ZDM_PREPARE_TGT ............... COMPLETED
ZDM_SETUP_TDE_TGT ............. COMPLETED
ZDM_RESTORE_TGT ............... COMPLETED
ZDM_RECOVER_TGT ............... COMPLETED
ZDM_FINALIZE_TGT .............. COMPLETED
ZDM_CONFIGURE_DG_SRC .......... COMPLETED
ZDM_SWITCHOVER_SRC ............ COMPLETED
ZDM_SWITCHOVER_TGT ............ COMPLETED
ZDM_POST_DATABASE_OPEN_TGT .... COMPLETED
ZDM_DATAPATCH_TGT ............. COMPLETED
ZDM_MANIFEST_TO_CLOUD ......... COMPLETED
ZDM_POST_MIGRATE_TGT .......... COMPLETED
ZDM_POSTUSERACTIONS ........... COMPLETED
ZDM_POSTUSERACTIONS_TGT ....... COMPLETED
ZDM_CLEANUP_SRC ............... COMPLETED
ZDM_CLEANUP_TGT ............... COMPLETED

Esempio 5-7 Ripristino da file di risposta servizio

TGT_DB_UNIQUE_NAME=z12tgt1s_uniq
MIGRATION_METHOD=ONLINE_PHYSICAL
DATA_TRANSFER_MEDIUM=DIRECT
PLATFORM_TYPE=EXACC
SRC_HTTP_PROXY_URL=
SRC_HTTP_PROXY_PORT=
SRC_CONFIG_LOCATION=
SRC_BASTION_HOST_IP=
SRC_BASTION_PORT=
SRC_BASTION_USER=
SRC_BASTION_IDENTITY_FILE=
SRC_HOST_IP=
SRC_TIMEZONE=
SRC_OSS_PROXY_HOST=
SRC_OSS_PROXY_PORT=
SRC_SSH_RETRY_TIMEOUT=
SRC_PDB_NAME=
SRC_DB_LISTENER_PORT=
TGT_HTTP_PROXY_URL=
TGT_HTTP_PROXY_PORT=
TGT_CONFIG_LOCATION=
TGT_BASTION_HOST_IP=
TGT_BASTION_PORT=
TGT_BASTION_USER=
TGT_BASTION_IDENTITY_FILE=
TGT_HOST_IP=
TGT_SSH_TUNNEL_PORT=
TGT_SSH_RETRY_TIMEOUT=
TGT_OSS_PROXY_HOST=
TGT_OSS_PROXY_PORT=
TGT_DATADG=
TGT_REDODG=
TGT_RECODG=
TGT_DATAACFS=
TGT_REDOACFS=
TGT_RECOACFS=
BACKUP_PATH=
HOST=
OPC_CONTAINER=
SRC_ZDLRA_WALLET_LOC=
TGT_ZDLRA_WALLET_LOC=
ZDLRA_CRED_ALIAS=
NONCDBTOPDB_CONVERSION=FALSE
NONCDBTOPDB_SWITCHOVER=TRUE
SKIP_FALLBACK=TRUE
TGT_RETAIN_DB_UNIQUE_NAME=
TGT_SKIP_DATAPATCH=FALSE
MAX_DATAPATCH_DURATION_MINS=
DATAPATCH_WITH_ONE_INSTANCE_RUNNING=
SHUTDOWN_SRC=
SKIP_SRC_SERVICE_RETENTION=
SRC_RMAN_CHANNELS=6
TGT_RMAN_CHANNELS=16
ZDM_LOG_OSS_PAR_URL=
ZDM_BACKUP_FULL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_INCREMENTAL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_DIFFERENTIAL_SRC_MONITORING_INTERVAL=10
ZDM_CLONE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RESTORE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RECOVER_TGT_MONITORING_INTERVAL=10
ZDM_BACKUP_RETENTION_WINDOW=
ZDM_BACKUP_TAG=
ZDM_USE_EXISTING_BACKUP=
ZDM_OPC_RETRY_WAIT_TIME=
ZDM_OPC_RETRY_COUNT=
ZDM_SRC_TNS_ADMIN=
ZDM_CURL_LOCATION=
ZDM_USE_EXISTING_UNDO_SIZE=
ZDM_SKIP_DG_CONFIG_CLEANUP=
ZDM_RMAN_COMPRESSION_ALGORITHM=LOW
ZDM_SRC_DB_RESTORE_SERVICE_NAME=
ZDM_RMAN_DIRECT_METHOD=

Durante l'upgrade cloud non in loco alla nuova infrastruttura Oracle Exadata Database Service on Cloud@Customer Gen2

Monitoraggio: Oracle monitorerà l'installazione di Oracle Exadata Database Service on Cloud@Customer Gen2 dall'inizio dell'installazione, proprio come avviene per un'installazione Gen2 regolare.

Backup: i backup vengono eseguiti dal cluster VM Exadata Cloud@Customer Gen1 e continueranno a funzionare durante l'upgrade. Dopo la migrazione a Oracle Exadata Database Service on Cloud@Customer Gen2, i backup nel servizio di storage degli oggetti (OSS) Oracle Cloud At Customer (OCC) Gen1 non sono consentiti e è necessario utilizzare i metodi di backup supportati per Oracle Exadata Database Service on Cloud@Customer Gen2.

Esegui upgrade del cloud non in loco alla nuova infrastruttura Oracle Exadata Database Service on Cloud@Customer Gen2

L'upgrade sposterà le tue risorse nel piano di controllo Gen 2 Cloud di Oracle Exadata Database Service on Cloud@Customer e nell'hardware di nuova generazione.

Utilizza la console OCI Gen2 per gestire l'infrastruttura, i cluster, i database e gli utenti/gruppi di Oracle Exadata Database Service on Cloud@Customer Gen2.

Lo stack software viene aggiornato alle versioni più recenti, ad esempio come indicato di seguito.

  • Software Exadata: 19.x o versione successiva
  • Oracle Grid Infrastructure: 19c
  • Sistema operativo per VM guest: Oracle Linux 7
  • DBaaS Strumenti: 20.x
  • CSI: sarà disponibile un nuovo CSI per l'account cloud.
Nota

Quando si esegue l'upgrade al nuovo hardware Gen2, lo stack software verrà aggiornato alle versioni più recenti in quel momento.

Applicazione delle patch: il processo e la notifica di applicazione delle patch dell'infrastruttura sono diversi in Gen2. Per ulteriori informazioni, vedere Gestione di un sistema Exadata Cloud@Customer.

Nota

Dopo la migrazione a Exadata Cloud@Customer Gen2, Oracle consiglia di utilizzare i metodi di backup supportati per Exadata Cloud@Customer Gen2. È tua responsabilità gestire manualmente qualsiasi backup nel servizio di storage degli oggetti (OSS) Oracle Cloud At Customer (OCC) Gen1 e Oracle non lo offre tramite la console, l'API o l'interfaccia CLI OCI.

Best practice per l'upgrade cloud fuori sede alla nuova infrastruttura Oracle Exadata Database Service on Cloud@Customer Gen2

Ai fini dell'aggiornamento, lo strumento consigliato da utilizzare è Oracle Zero Downtime Migration (ZDM).

Di seguito sono riportate alcune delle procedure ottimali consigliate nel contesto dell'uso di ZDM per l'aggiornamento da Gen1 a Gen2.

  • Sebbene tutti i metodi di migrazione fisica siano supportati, si consiglia di utilizzare la migrazione in linea con trasferimento dati diretto.
    Nota

    Si sconsiglia di utilizzare Gen1 Oracle Cloud At Customer OSS o OCI Object Storage per questa migrazione.
  • Impostare ZDM_RMAN_COMPRESSION_ALGORITHM su LOW.
  • La Oracle home del database di destinazione deve avere lo stesso livello di patch o un livello di patch superiore dell'origine.
  • La Oracle home del database di destinazione deve avere tutte le patch singole come Oracle home di origine.
  • Eseguire un'esecuzione di convalida prima dell'esecuzione effettiva.
  • Per un database di origine CDB, è necessario che tutti i PDB nell'origine siano in linea.