1. Esegui il provisioning e distribuisci una soluzione di massima disponibilità per PeopleSoft su Oracle Cloud
  2. Configura per migrazione database
  3. Imposta database primario futuro

Imposta database primario futuro

Configurerai il futuro Oracle Exadata Database Service on Dedicated Infrastructure primario e configurerai Oracle Zero Downtime Migration per prepararti a migrare il database PeopleSoft su OCI.

Informazioni sui prerequisiti di Oracle Zero Downtime Migration

Di seguito sono riportati i prerequisiti più importanti per Oracle Zero Downtime Migration (ZDM) per una migrazione di successo:

  1. Server host ZDM

    Eseguire il provisioning di un host o di una VM dedicata per ospitare l'installazione ZDM, che include un footprint di Oracle Clusterware di piccole dimensioni, un database MySQL e Fleet Patching and Provisioning. Per questo server deve essere installata l'immagine più recente di Oracle Linux 7. Questa forma VM può essere di piccole dimensioni, bastano 2 core con 16 GB di RAM fisica. Il server ZDM orchestra tutti i task di migrazione del database sia nei sistemi di origine che in quelli di destinazione.

  2. Connessione di rete
    Il tipo di connettività di rete disponibile dall'ambiente on premise alle risorse nell'infrastruttura OCI determinerà il metodo di migrazione ZDM e le opzioni di trasferimento dati. Oracle Zero Downtime Migration consente diverse topologie di connettività di rete, incluse le connessioni dirette tramite OCI FastConnect o IPSec VPN, l'uso di tunnel SSH, server proxy e host bastion.

    Nota

    È estremamente importante capire in che modo i sistemi on-premise accederanno alle risorse OCI e se le risorse OCI devono accedere a sistemi on-premise specifici e, in caso affermativo, in quale percorso di rete.
    Considerare quanto riportato di seguito.
    1. Il server host ZDM deve essere in grado di accedere sia ai sistemi di origine on premise che ai sistemi di destinazione OCI
    2. Per i metodi di migrazione ONLINE che utilizzano Oracle Data Guard, i sistemi di origine e destinazione devono essere in grado di accedervi a vicenda.
  3. Cifratura dei dati trasparente (TDE)

    OCI richiede che tutti i database siano cifrati. Se non è possibile cifrare i dati stessi prima del trasferimento del database in OCI, è possibile creare un wallet del keystore TDE nell'origine e il processo di migrazione ZDM cifrerà i file di dati nella destinazione. È necessario un wallet TDE nell'origine per le versioni del database 12.2 e successive, ma è possibile utilizzare questo metodo per le release del database precedenti.

    Per i passi per l'impostazione del keystore TDE, vedere "Impostazione del keystore di cifratura dei dati trasparente" in Sposta in Oracle Cloud utilizzando la migrazione senza tempi di inattività.

  4. Database segnaposto
    È necessario creare un database segnaposto nell'Oracle Exadata Database Service on Dedicated Infrastructure di destinazione prima di eseguire la migrazione con Oracle Zero Downtime Migration. ZDM rimuoverà le strutture dati del database segnaposto come parte del processo di migrazione, con le strutture del database di origine ripristinate al suo posto. I suoi metadati rimarranno in vigore. Utilizzare OCI Console per crearla, con i seguenti vincoli:
    1. La home del database deve avere lo stesso livello di versione, release e patch del software primario.
    2. Il valore DB_NAME deve essere uguale a quello del database primario.
    3. Il valore DB_UNIQUE_NAME può essere lasciato vuoto o specificato, ma deve essere diverso dal valore primario.
    4. La password SYS deve essere uguale a quella del database primario, in quanto stiamo utilizzando Oracle Data Guard.
    5. Non creare un database collegabile (PDB) in questo database container (CDB).
    6. Non configurare i backup automatici durante il provisioning di questo database
  5. accesso SSH

    Oracle Zero Downtime Migration richiede l'accesso SSH sia ai sistemi di origine che a quelli di destinazione. Per la destinazione, si utilizzeranno l'utente cloud opc e le chiavi SSH senza password. Per un'origine in locale, verrà utilizzato l'utente root. È possibile configurare chiavi SSH senza password e utilizzarle senza passphrase oppure utilizzare l'utente e la password root. Per impostare l'accesso SSH e assicurarsi che il server host ZDM possa accedere ai sistemi di origine e di destinazione, vedere Oracle Zero Downtime Migration.

Nota

Per una descrizione completa dei prerequisiti per Oracle Zero Downtime Migration, vedere Passa a Oracle Cloud utilizzando Zero Downtime Migration.

Configurare Oracle Zero Downtime Migration per la migrazione del database

Dopo aver risolto i prerequisiti e aver installato Oracle Zero Downtime Migration, è possibile creare un file di risposta per configurare la migrazione del database.

  1. Copiare il modello di file di risposta trovato in $ZDM_HOME/rhp/zdm/template/zdm_template.rsp nella directory di lavoro sul server host Oracle Zero Downtime Migration.
  2. Modificare il file di risposta per la migrazione del database.
    Sono disponibili diversi parametri per controllare la migrazione.
    Ad esempio, puoi impostare la migrazione fino a configurare Oracle Data Guard e Oracle Data Guard Broker e ridurre al minimo i tempi di inattività:
    Parametro ZDM Valore Commenti
    TGT_DB_UNIQUE_NAME CDBHCM_iad1dx Specifica il valore db_unique_name del database segnaposto.
    MIGRATION_METHOD ONLINE_PHYSICAL Metodo di migrazione utilizzato da Oracle Zero Downtime Migration che non richiede che il database primario sia inattivo.
    DATA_TRANSFER_MEDIUM OSS Oracle Zero Downtime Migration utilizza il servizio OCI Object Storage per posizionare nell'area intermedia il backup del database e poi eseguirne il ripristino. È possibile utilizzare altri metodi di trasferimento, ad esempio DIRECT, che possono utilizzare RMAN RESTORE FROM SERVICE senza dover posizionare il database nell'area intermedia dello storage degli oggetti. Per DIRECT, sono necessari altri parametri di Oracle Zero Downtime Migration, consulta la documentazione su Oracle Zero Downtime Migration.
    PLATFORM_TYPE ExaCS1 Il sistema di destinazione per la migrazione è Exadata Cloud Service.
    TGT_RETAIN_DB_UNIQUE_NAME TRUE Affinché Oracle Data Guard rispedisca i log all'origine, il database di destinazione (TGT) DB_UNIQUE_NAME viene conservato durante il processo di migrazione.
    TGT_SKIP_DATAPATCH TRUE Salta la patch dati in esecuzione nel database di destinazione.
    SHUTDOWN_SRC FALSE Non chiudere il database di origine una volta completata la migrazione.
    SRC_RMAN_CHANNELS 10 Oracle Recovery Manager (RMAN) allocherà 10 canali nel database di origine per il backup parallelo del database.
    TGT_RMAN_CHANNELS 10 Oracle RMAN allocherà 10 canali nel database di destinazione per il ripristino parallelo del database.
    ZDM_USE_DG_BROKER TRUE Oracle Zero Downtime Migration configurerà il broker Oracle Data Guard come parte del processo di migrazione.
    HOST https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/maacloud URL dell'endpoint del servizio OCI Object Storage. Necessario per il supporto di trasferimento dati OCI Object Storage.
    OPC_CONTAINER ZDM_Backup Nome bucket OCI Object Storage. Necessario per il supporto di trasferimento dati OCI Object Storage.

    [1] Il valore accettato per PLATFORM_TYPE per Oracle Exadata Database Service on Dedicated Infrastructure è ExaCS.

  3. Determinare i parametri e le impostazioni rimanenti appropriati per lo scenario.
    Nel nostro esempio, siamo stati in grado di accettare i valori predefiniti per i parametri rimanenti. Per i dettagli, consulta la documentazione di Oracle Zero Downtime Migration.

Eseguire il test del file di configurazione e dei parametri di Oracle Zero Downtime Migration

Per eseguire il test dei passi di preparazione e del file di configurazione, eseguire Oracle Zero Downtime Migration in modalità di valutazione.

L'opzione della riga di comando -eval indica a Oracle Zero Downtime Migration di eseguire controlli preliminari solo per tutte le relative fasi del processo di migrazione, quindi di eseguire l'arresto. Non vengono apportate modifiche ai sistemi. I controlli preliminari di Oracle Zero Downtime Migration vengono eseguiti su entrambi i database di origine e di destinazione e, se DATA_TRANSFER_MEDIUM è impostato su OSS, su OCI Object Storage.
  1. Eseguire controlli preliminari del processo di migrazione.
    Di seguito sono riportati alcuni esempi. 
    $ZDM_HOME/bin/zdmcli migrate database \
 -sourcedb CDBHCM_sca6dp \
 -sourcenode scaqan10dv0505.example.com \
 -srcauth zdmauth \
 -srcarg1 user:opc \
 -srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk \
 -srcarg3 sudo_location:/usr/bin/sudo \
 -targetnode iadexadb-bw5wn1.ebsexadbprivate.ebscloudmaavcn.oraclevcn.com \
 -backupuser <oci user name> \
 -rsp /home/zdmuser/zdm_CDBHCM_migration.rsp \
 -tgtauth zdmauth \
 -tgtarg1 user:opc \
 -tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk \
 -tgtarg3 sudo_location:/usr/bin/sudo \
 -eval

    Tutti i job di Oracle Zero Downtime Migration vengono eseguiti tramite un meccanismo di pianificazione dei job e in modalità asincrona. Quando viene eseguito un comando Oracle Zero Downtime Migration, si riceverà un ID job che è possibile utilizzare per controllare lo stato del job.

  2. Controlla lo stato del tuo lavoro.
    Ad esempio, eseguire il comando seguente per eseguire una query sullo stato del job con ID 5:
    $ $ZDM_HOME/bin/zdmcli query job -jobid 5
    L'output indica il task in esecuzione, i task in sospeso e se i controlli preliminari sono riusciti o non riusciti. Durante la query sullo stato del job, è possibile visualizzare l'avanzamento fino a quando il job non ha eseguito tutti i task obbligatori.
  3. Eseguire zdmcli con -eval il numero di volte necessario per il superamento di tutti i controlli preliminari.
    Se un task è contrassegnato da PRECHECK_FAILED, consultare il file di log "Risultato" per individuare eventuali errori e correggerli.
  4. Prima di eseguire una migrazione effettiva, assicurarsi che la modalità di valutazione restituisca PRECHECK_PASSED per tutti i task di controllo preliminare.
    Di seguito sono riportati alcuni esempi. 
    iad-zdm. ebsexadbprivate.ebscloudmaavcn.oraclevcn.com: Audit ID: 50
Job ID: 5
User: zdmuser
Client: iad-zdm
Job Type: "EVAL"
Scheduled job command: "zdmcli migrate database -sourcedb CDBHCM_sca6dp -sourcenode scaqan10dv0505.mycompany.com -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -srcarg3 sudo_location:/usr/bin/sudo -targetnode iadexadb-bw5wn1.ebsexadbprivate.ebscloudmaavcn.oraclevcn.com -backupuser <oci user name> -rsp /home/zdmuser/zdm_CDBHCM_migration.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -tgtarg3 sudo_location:/usr/bin/sudo -eval"
Scheduled job execution start time: 2022-07-26T20:26:01Z. Equivalent local time: 2022-07-26 20:26:01
Current status: SUCCEEDED
Result file path: "/u01/app/zdmbase/chkbase/scheduled/job-5-2022-07-26-20:26:21.log"
Metrics file path: "/u01/app/zdmbase/chkbase/scheduled/job-5-2022-07-26-20:26:21.json"
Job execution start time: 2022-07-26 20:26:21
Job execution end time: 2022-07-26 20:30:37
Job execution elapsed time: 4 minutes 16 seconds
ZDM_GET_SRC_INFO ........... PRECHECK_PASSED
ZDM_GET_TGT_INFO ........... PRECHECK_PASSED
ZDM_PRECHECKS_SRC .......... PRECHECK_PASSED
ZDM_PRECHECKS_TGT .......... PRECHECK_PASSED
ZDM_SETUP_SRC .............. PRECHECK_PASSED
ZDM_SETUP_TGT .............. PRECHECK_PASSED
ZDM_PREUSERACTIONS ......... PRECHECK_PASSED
ZDM_PREUSERACTIONS_TGT ..... PRECHECK_PASSED
ZDM_OBC_INST_SRC ........... PRECHECK_PASSED
ZDM_OBC_INST_TGT ........... PRECHECK_PASSED
ZDM_VALIDATE_SRC ........... PRECHECK_PASSED
ZDM_VALIDATE_TGT ........... PRECHECK_PASSED
ZDM_POSTUSERACTIONS ........ PRECHECK_PASSED
ZDM_POSTUSERACTIONS_TGT .... PRECHECK_PASSED
ZDM_CLEANUP_SRC ............ PRECHECK_PASSED
ZDM_CLEANUP_TGT ............ PRECHECK_PASSED

Eseguire la migrazione del database PeopleSoft

È possibile utilizzare Oracle Zero Downtime Migration per eseguire la migrazione del database. Per impostazione predefinita, eseguirà la migrazione del database e quindi lo switchover.

Nota

NON si desidera che Oracle Zero Downtime Migration esegua lo switchover, pertanto verrà utilizzata la clausola -stopafter per l'arresto dopo il completamento della fase ZDM_CONFIGURE_DG_SRC.

  1. Eseguire il processo di migrazione del database e specificare -stopafter per arrestare la migrazione.
    Di seguito sono riportati alcuni esempi. 
    $ZDM_HOME/bin/zdmcli migrate database \
 -sourcedb CDBHCM_sca6dp \
 -sourcenode scaqan10dv0505.mycompany.com \
 -srcauth zdmauth \
 -srcarg1 user:opc \
 -srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk \
 -srcarg3 sudo_location:/usr/bin/sudo \
 -targetnode iadexadb-bw5wn1.ebsexadbprivate.ebscloudmaavcn.oraclevcn.com \
 -backupuser <oci user name> \
 -rsp /home/zdmuser/zdm_CDBHCM_migration.rsp \
 -tgtauth zdmauth \
 -tgtarg1 user:opc \
 -tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk \
 -tgtarg3 sudo_location:/usr/bin/sudo \
 -stopafter ZDM_CONFIGURE_DG_SRC

    Il comando restituisce un ID job che è possibile utilizzare per controllare lo stato del job.

  2. Controlla lo stato del tuo lavoro.
    Ad esempio, eseguire il comando seguente per eseguire una query sullo stato del job con ID 6:
    $ $ZDM_HOME/bin/zdmcli query job -jobid 6

    Di seguito è riportato un esempio dell'output finale dopo aver completato la fase ZDM_CONFIGURE_DB_SRC. 

    iad-zdm. ebsexadbprivate.ebscloudmaavcn.oraclevcn.com: Audit ID: 74
Job ID: 6
User: zdmuser
Client: iad-zdm
Job Type: "MIGRATE"
Scheduled job command: "zdmcli migrate database -sourcedb CDBHCM_sca6dp -sourcenode scaqan10dv0505.mycompany.com -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -srcarg3 sudo_location:/usr/bin/sudo -targetnode iadexadb-bw5wn1.ebsexadbprivate.ebscloudmaavcn.oraclevcn.com -backupuser <oci user name> -rsp /home/zdmuser/zdm_CDBHCM_migration.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -tgtarg3 sudo_location:/usr/bin/sudo -pauseafter ZDM_CONFIGURE_DG_SRC"
Scheduled job execution start time: 2022-07-26T20:35:24Z. Equivalent local time: 2022-07-26 20:35:24
Current status: PAUSED
Current Phase: "ZDM_CONFIGURE_DG_SRC"
Result file path: "/u01/app/zdmbase/chkbase/scheduled/job-6-2022-07-26-20:35:51.log"
Metrics file path: "/u01/app/zdmbase/chkbase/scheduled/job-6-2022-07-26-20:35:51.json"
Job execution start time: 2022-07-26 20:35:51
Job execution end time: 2022-07-26 21:37:05
Job execution elapsed time: 1 hours 1 minutes 14 seconds
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_OBC_INST_SRC ............... COMPLETED
ZDM_OBC_INST_TGT ............... COMPLETED
ZDM_VALIDATE_SRC ............... COMPLETED
ZDM_VALIDATE_TGT ............... COMPLETED
ZDM_BACKUP_FULL_SRC ............ COMPLETED
ZDM_BACKUP_INCREMENTAL_SRC ..... COMPLETED
ZDM_DISCOVER_SRC ............... COMPLETED
ZDM_COPYFILES .................. COMPLETED
ZDM_PREPARE_TGT ................ COMPLETED
ZDM_SETUP_TDE_TGT .............. COMPLETED
ZDM_CLONE_TGT .................. COMPLETED
ZDM_FINALIZE_TGT ............... COMPLETED
ZDM_CONFIGURE_DG_SRC ........... COMPLETED

Quando questo comando completa il passo ZDM_CONFIGURE_DG_SRC, Oracle Zero Downtime Migration ha copiato il database di origine in OCI, lo ha impostato come database in standby dell'origine, ha configurato il broker Data Guard e ha avviato redo apply. Il nuovo standby OCI è in fase di sincronizzazione con il database primario di origine.

Oracle Zero Downtime Migration ha inoltre completato i task riportati di seguito.

  • Ha registrato il database migrato in Oracle Clusterware
  • Aggiornati i metadati del piano di controllo OCI con informazioni aggiornate, inclusi eventuali database collegabili (PDB) all'interno del database di standby
  • I file di dati del database di standby sono stati cifrati utilizzando la Cifratura dei dati trasparente (TDE), come indicato nei prerequisiti di Oracle Zero Downtime Migration.

    Nota

    Il valore WALLET_TYPE nella vista V$ENCRYPTION_WALLET è impostato su AUTOLOGIN.

Definizione servizi database basati su ruoli per primario futuro

Aggiungere i servizi di database basati sui ruoli che l'applicazione PeopleSoft utilizzerà quando il database OCI ricoprirà il ruolo PRIMARY, sia per gli utenti in linea che per lo scheduler dei processi.

  • Aggiungere servizi di database basati su ruoli per gli utenti in linea e lo scheduler dei processi.
    srvctl add service -db CDBHCM_iad1dx -pdb HR92U033 -service HR92U033_BATCH -preferred "CDBHCM1,CDBHCM2" -notification TRUE -role PRIMARY,SNAPSHOT_STANDBY -failovermethod BASIC -failovertype AUTO -failoverretry 10 -failoverdelay 3

srvctl add service -db CDBHCM_iad1dx -pdb HR92U033 -service HR92U033_ONLINE -preferred "CDBHCM1,CDBHCM2" -notification TRUE -role PRIMARY,SNAPSHOT_STANDBY -failovermethod BASIC -failovertype AUTO -failoverretry 10 -failoverdelay 3