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

Imposta database secondario futuro

Dopo aver stabilito il primo standby fisico in Oracle Cloud Infrastructure (OCI), ne creerai un secondo in un'altra region. Questo secondo database è il database nel tuo ambiente di disaster recovery basato su cloud.

La funzionalità Oracle Data Guard cascade standby, in cui il secondo standby riceve il proprio redo dal primo standby, non direttamente dal database primario on-premise, riduce il traffico di rete dal sito host on-premise. Stabilirà anche quale sarà il principale percorso di propagazione redo.

Al momento, ci sono vincoli che ci impediscono di utilizzare gli strumenti OCI per stabilire e gestire completamente il nostro futuro database di disaster recovery. Il servizio cloud di associazione Oracle Data Guard attualmente non è in grado di registrare una relazione di database di standby esistente e non sarà in grado di gestire la configurazione del database di standby. Pertanto, ad esempio, non è possibile utilizzare Oracle Managed Disaster Recovery Cloud Service.

Poiché entrambi i database di standby sono stati creati con un database segnaposto basato su OCI, il piano di controllo OCI può gestire l'applicazione di patch e altre attività del ciclo di vita per ciascuno di essi.

Crea database segnaposto

Utilizzare OCI Console per creare un nuovo database segnaposto in un'area diversa (consigliato) o in un dominio di disponibilità diverso nella stessa area.

Attenersi alla procedura riportata di seguito. NON eliminare il database segnaposto utilizzando strumenti quali OCI o dbaascli.
  1. Selezionare Exadata On Oracle Public Cloud. Scegliere il servizio Oracle Exadata Database Service on Dedicated Infrastructure su cui si desidera distribuire il database.

    Attenersi ai vincoli riportati di seguito.

    • La home del database deve avere la stessa versione software, release e livello di patch dell'origine.
    • DB_NAME deve essere lo stesso del database primario e del primo database in standby.
    • Il valore DB_UNIQUE_NAME può essere lasciato vuoto o specificato, ma deve essere diverso sia dal database primario in locale che dal primo database in standby fisico.
    • Non configurare i backup automatici durante il provisioning di questo database.
    • Non specificare un nome PDB durante il provisioning di questo database.
  2. Acquisisci i dati di configurazione in standby a catena.
    1. Eseguire il login come utente del sistema operativo oracle su uno dei nodi di database che ospitano il database dei segnaposto appena creato.
    2. Origine dell'ambiente per questo database.
    3. Eseguire il comando seguente utilizzando il comando DB_UNIQUE_NAME:
    $ srvctl config database -db DB_UNIQUE_NAME
    Salvare i dati di configurazione. Verranno utilizzati in diversi passaggi riportati di seguito.
  3. Chiude il database segnaposto.
    $ srvctl stop database -db cascade standby placeholder database -stopoption immediate
  4. Eseguire il login come utente del sistema operativo Grid. Utilizzando il comando asmcmd, svuotare i file nelle directory sotto +DATAC1/DB_UNIQUE_NAME:
    1. DATAFILE
    2. ONLINELOG
    3. Tutto PDB GUID/DATAFILE
    4. Tutti i control file sotto +DATAC1/DB_UNIQUE_NAME/CONTROLFILE
    5. Il password file specificato nei dati di configurazione acquisiti al passo 1
  5. In +RECOC1/DB_UNIQUE_NAME, rimuovere i file nelle directory ARCHIVELOG, AUTOBACKUP e FLASHBACKLOG.
  6. Non rimuovere spfile.

Prepara per ripristino database

Configurare la nuova Oracle home in preparazione del ripristino del database.

  • Regolare il file tnsnames.ora in ogni ambiente per essere a conoscenza di ciascuno degli altri database. Verificare le comunicazioni tra ambienti.
  • Copiare il password file dal primo database di standby.
  • Copiare il wallet Transparent Data Encryption (TDE) dal primo database di standby.
  • Regolare i parametri del database per il database in standby in cascata.

Configura TNS per standby in cascata

Regolare il file tnsnames.ora in ogni ambiente per essere a conoscenza di ciascuno degli altri database. Verificare le comunicazioni tra ambienti.

Il broker Data Guard deve essere in grado di comunicare con ogni database nella configurazione, indipendentemente dall'istanza a cui è connesso. Oracle Zero Downtime Migration ha eseguito questa configurazione per la relazione di standby iniziale. È necessario aggiungere il database in standby in cascata nella configurazione:
  • Aggiungere la stringa di connessione TNS per il database di standby in cascata ai file tnsnames.ora utilizzati da tutte le istanze di Oracle Real Application Clusters (Oracle RAC) del database primario in locale e del primo database di standby.
  • Aggiungere le stringhe di connessione TNS per il database primario in locale e il primo database di standby OCI ai file tnsnames.ora utilizzati da tutte le istanze Oracle RAC del database di standby in cascata.
Ciascuna voce TNS deve utilizzare gli indirizzi SCAN IP, non il nome SCAN. Di seguito è riportato un esempio di voce TNS conforme creata da Oracle Zero Downtime Migration per il primo database in standby. 
CDBHCM_iad1dx =
          (DESCRIPTION =
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  1>) (PORT = 1521))
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  2>) (PORT = 1521))
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  3>)) (PORT = 1521))
            (CONNECT_DATA =
              (SERVER = DEDICATED)
              (SERVICE_NAME = CDBHCM_iad1dx)
              (FAILOVER_MODE =
                  (TYPE = select)
                  (METHOD = basic)
              )
              (UR=A)
             )
          )

È necessario eseguire il login a ciascun database server come utente del sistema operativo oracle, eseguire l'origine dell'ambiente, quindi modificare la directory in $TNS_ADMIN.

  1. Per ogni istanza Oracle RAC sia del database primario in locale che del primo database di standby OCI, modificare il file tnsnames.ora e aggiungere la stringa di connessione TNS del database di standby in cascata.
  2. Per ogni istanza Oracle RAC del database in standby in cascata OCI, modificare il file tnsnames.ora e aggiungere le stringhe di connessione TNS sia per il database primario in locale che per il primo database in standby OCI.
  3. Eseguire il ping del primo database di standby dal database di standby in cascata utilizzando la utility tnsping con l'alias della stringa di connessione aggiunto.
    $ tnsping CDBHCM_iad1dx
    Questo valore deve restituire OK con tempo di latenza in millisecondi. Se non viene restituito OK, verificare la presenza di errori e individuare l'indirizzo di conseguenza.
  4. Eseguire il test della connessione da ciascun database server che ospiterà il database di standby in cascata al primo database di standby (CDBHCM_iad1dx) utilizzando SQL*Plus. Sarà necessaria la password SYS per il database primario.
    $ sqlplus sys/<password>@CDBHCM_iad1dx as sysdba
    Correggere gli errori e ripetere l'operazione fino a quando non è possibile connettersi correttamente.

Copia il password file

Copiare il password file dal primo database di standby.

  1. Eseguire il login a uno dei server che ospitano il primo database di standby (CDBHCM_iad1dx) come utente del sistema operativo oracle.
  2. Utilizzare srvctl per determinare la posizione del password file per questo database, quindi copiarlo nella directory /tmp.
    Per determinare la posizione radice del wallet, eseguire le operazioni riportate di seguito come sysdba.
    $ srvctl config database -db first standby db name
  3. Cercare la riga con la dicitura "File password:" e registrarne la posizione (percorso di Oracle Automatic Storage Management (Oracle ASM)).
  4. Diventare l'utente del sistema operativo Grid e utilizzare il comando asmcmd per copiare il password file nella directory /tmp:
    $ asmcmd -p
asmcmd> cd +DATAC1/path from step 3
asmcmd> cp <password file name> /tmp/password file name
  5. Trasferire il password file in una posizione temporanea su uno dei database server in standby a catena utilizzando scp o con qualsiasi mezzo utilizzato per trasferire i file all'interno di OCI.
  6. Eseguire il login al database server in standby in cascata in cui è stato inserito il password file come utente del sistema operativo Grid. Copiare il password file in Oracle ASM, utilizzando la posizione specificata nei dati di configurazione in standby a catena precedenti.
    $ asmcmd -p --privilege sysdba
asmcmd> pwcopy –dbuniquename cascade standby db unique name /tmp/password-file-name +ASM Diskgroup/path/password-file-name -f
    Di seguito sono riportati alcuni esempi.
    asmcmd> pwcopy –dbuniquename CDBHCM_phx5s   /tmp/password file name +DATAC1/CDBHCM_phx5s/PASSWORD/orapwCDBHCM_phx5s -f
  7. Assicurarsi che tutte le stringhe di connessione TNS siano configurate correttamente verificando che ogni database possa connettersi a tutti gli altri database. Correggere gli eventuali errori di connessione per i seguenti tentativi di connessione non riusciti.
    1. Dal database (primario) in locale:
      $ sqlplus sys/password@first standby db as sysdba
$ sqlplus sys/password@cascade standby db as sysdba
    2. Dal primo standby fisico:
      $ sqlplus sys/password@on-prem primary as sysdba
$ sqlplus sys/password@cascade standby db as sysdba
    3. Dal standby fisico in cascata:
      $ sqlplus sys/password@on-prem primary as sysdba
$ sqlplus sys/password@first standby db as sysdba
    Non continuare finché tutti i tentativi di connessione non avranno esito positivo.

Copiare il wallet TDE

Copiare il wallet Transparent Data Encryption (TDE) dal primo database di standby. In Oracle Exadata Database Service on Dedicated Infrastructure, la posizione utilizzata dagli strumenti cloud per memorizzare i wallet TDE si trova in Oracle Advanced Cluster File System (Oracle ACFS), che tutti i database server nel cluster condividono.
  1. Eseguire il login a uno dei server che ospitano il primo database di standby (CDBHCM_iad1dx) come utente del sistema operativo oracle e passare alla directory della posizione radice del wallet.
    Per determinare la posizione radice del wallet, eseguire le operazioni riportate di seguito come sysdba.
    $ sqlplus / as sysdba
SQL> show wallet_root
$ cd wallet root location from “show wallet_root” above
  2. Andare alla posizione radice del wallet e comprimere la directory tde.
    La directory tde si trova nella directory indicata al passo 1, in genere /var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root. 
    $ zip -r CDBHDM_tde_wallet.zip  tde
  3. Trasferire questo file ZIP in uno dei database server che ospiteranno il database in cascata (CDBHCM_phx5s) in una posizione temporanea (ad esempio, /tmp).
    Utilizza scp o con qualsiasi mezzo utilizzi per trasferire i file all'interno di OCI.
  4. Eseguire il login ai database server che ospiteranno il database in cascata (CDBHCM_phx5s) e sul quale è stato posizionato il file zip, come utente del sistema operativo oracle e modificare la directory nella posizione radice del wallet.

    La posizione deve essere uguale a quella precedente, poiché DB_NAME è uguale (CDBHCM). 

    $ cd /var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root
  5. Spostare la directory TDE esistente su un nome diverso.
    $ mv tde tde_date
  6. Spostare il file ZIP contenente il wallet TDE (CDBHDM_tde_wallet.zip) creato nel passo 2 nel percorso seguente:/var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root.
    Sostituire DB_NAME con il nome del database.
  7. Estrarre il file CDBHDM_tde_wallet.zip.
    $ unzip CDBHDM_tde_wallet.zip

In questo modo viene creata una nuova sottodirectory tde con i file wallet dal primo database di standby fisico.

Adeguare i parametri del database per la sovrapposizione in standby

Finalizzare la configurazione del database di standby in cascata.

  1. Eseguire il login a uno dei server che ospitano il primo database di standby (CDBHCM_iad1dx) come utente oracle OS e l'ambiente di origine. 
    $ . ./CDBHCM.env
  2. Creare un pfile dal primo database di standby da utilizzare come riferimento per la regolazione dei parametri nel database di standby in cascata.
    $ cd $ORACLE_HOME/dbs
$ sqlplus / as sysdba
SQL> create pfile=’tmp_CDBHCM_iad1dx_init.ora’ from spfile;
  3. Eseguire il login a uno dei database server che ospiteranno il database di standby in cascata (CDBHCM_phx5s) e l'ambiente di origine:
    $ . ./CDBHCM.env
  4. Avviare NOMOUNT su un'istanza.
    $ sqlplus / as sysdba
SQL> startup nomount
  5. Apportare le seguenti modifiche ai parametri del database per il database in cascata, facendo riferimento alla lista dei parametri del database dal Passo 2 precedente:
    SQL> alter system set control_files=’’ sid=’*’ scope=spfile;
SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance 1>’ scope=spfile;
SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance 2>’ scope=spfile;
SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance N>’ scope=spfile;
SQL> alter system set sga_target=’<Refer to the parameter list from step 2>’ sid=’*’ scope=spfile;
SQL> alter system set log_buffer=’<Refer to the parameter list from step 2>’ sid=’*’ scope=spfile;
  6. Regolare i parametri specifici di PeopleSoft.
    SQL> alter system set “_gby_hash_aggregation_enabled”=false sid=’*’ scope=spfile;
SQL> alter system set “_ignore_desc_in_index”=true sid=’*’ scope=spfile;
SQL> alter system set “_unnest_subquery”=true sid=’*’ scope=spfile;
SQL> alter system set nls_length_semantics='CHAR' sid=’*’ scope=spfile;

    Nota

    Non modificare i seguenti parametri:
    • DB_NAME
    • DB_UNIQUE_NAME
    • WALLET_ROOT
  7. Arrestare e riavviare NOMOUNT sull'istanza per implementare le modifiche.
    $ sqlplus / as sysdba
SQL> shutdown immediate
SQL> startup nomount

Ripristino del database in standby in cascata

Ripristinare il database sul footprint in standby a catena dal primo database in standby fisico. Utilizzare il comando Oracle Recovery Manager (RMAN) RESTORE FROM SERVICE per ripristinare il control file e i file di dati.

  1. Se l'istanza per lo standby in cascata non viene avviata, avviarla in NOMOUNT:
    $ sqlplus / as sysdba 
$ SQL> startup nomount
  2. Utilizzare RMAN per ripristinare il control file e i file di dati dal primo standby al database di standby in cascata.

    Nota

    Potrebbe essere necessario regolare il numero di canali RMAN per il "disco di tipo dispositivo" in modo da non saturare la rete. Se è necessaria una modifica, eseguire questa operazione prima di eseguire il comando "restore database from service". È possibile eseguire questa operazione con il seguente comando, sostituendo N come appropriato: 
    RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM N; 
    $ rman target / nocatalog
RMAN> restore standby controlfile from service ‘first standby db name’;
RMAN> alter database mount;
RMAN> restore database from service ‘first standby db name’ section size 8G;
RMAN> shutdown immediate;
RMAN> exit
  3. Riavviare tutte le istanze ed eseguire il MOUNT del database di standby in cascata utilizzando srvctl.
    $ srvctl start database -db cascade standby db unique name -startoption mount
  4. Creare e cancellare tutti i file di log in linea e in standby utilizzando lo script seguente.
    $ sqlplus “/ as sysdba”
SQL> set pagesize 0 feedback off linesize 120 trimspool on
SQL> spool /tmp/clearlogs.sql
SQL> select distinct 'alter database clear logfile group '||group#||';' from v$logfile;
SQL> spool off
  5. Ispezionare lo script clearlogs.sql generato prima di eseguirlo. L'istanza di database creerà e cancellerà i file di log in linea e in standby per tutti i thread. Quindi eseguire lo script.
    SQL> @/tmp/clearlogs.sql

Configurare il broker Data Guard per il database in standby in cascata

Il broker Data Guard è già stato configurato tra il database primario in locale e il primo database di standby OCI tramite Oracle Zero Downtime Migration, ora potrai aggiungere il database di standby in cascata alla configurazione.

Lo standby in cascata e i database in locale non comunicano direttamente tra loro. Se necessario, il relativo redo viene fornito tramite il primo database di standby on premise:

  • Quando il database in locale è primario, redo viene inviato dal database primario in locale a o tramite il primo standby, quindi al database in standby in cascata:
    • Primario on-premise per il primo standby OCI
    • Primo standby OCI allo standby a catena OCI
  • Quando il primo standby è nel ruolo primario, redo viene inviato da tale database direttamente sia ai database in standby on premise che a cascata:
    • OCI primaria per lo standby on premise
    • Da database primario OCI a database in standby a catena OCI
  • Se lo standby in cascata diventa primario in questa configurazione, il redo verrà inviato da tale database a o tramite il primo standby OCI, quindi al database in locale:
    • Primo standby OCI allo standby on premise
    • Cascata OCI primaria per il primo standby OCI
  1. Configurare il broker Data Guard nel database server che ospita lo standby in cascata. Eseguire il login a uno dei server di database che ospitano il database di standby in cascata come utente del sistema operativo oracle e utilizzare l'ambiente di origine. 
    $ sqlplus / as sysdba
SQL> alter system set dg_broker_config_file1=’+DTAC1/cascade standby db/DG/dr1 cascade standby db.dat’ sid=’*’ scope=both;
SQL> alter system set dg_broker_config_file2=’+RECOC1/cascade standby db/DG/dr2 cascade standby db.dat’ sid=’*’ scope=both;
SQL> alter system set dg_broker_start=TRUE sid=’*’ scope=both;
  2. Eseguire il login al database primario o al primo database in standby fisico e ottenere l'origine dell'ambiente. Aggiungere il nuovo standby in cascata alla configurazione del broker Data Guard esistente.
    $ dgmgrl 
DGMGRL>  connect sys/password
DGMGRL> show configuration
DGMGRL> add database 'cascade standby db’
 as connect identifier is cascade standby db;
  3. Aggiungere redo routes.
    DGMGRL> edit database on-premises db set property redoroutes='(LOCAL : first standby db ASYNC)';
DGMGRL> edit database first standby db set property redoroutes='(LOCAL : on-premises db ASYNC, cascade standby db ASYNC)(on-premises db : cascade standby db ASYNC)(cascade standby db : on-premises db ASYNC)';
DGMGRL> edit database cascade standby db set property redoroutes='(LOCAL : first standby db ASYNC)';
  4. Abilita il nuovo database in standby in cascata.
    DGMGRL> enable database cascade standby db;
  5. Una volta abilitato, il database in cascata inizierà a ricevere redo generato dal database primario in locale tramite il primo database in standby. Dall'interno del broker Data Guard, mostra la configurazione:
    DGMGRL> show configuration lag
Configuration - zdm_psfthcm_dg
  Protection Mode: MaxPerformance
  Members:
  CDBHCM_sca6dp  - Primary database
    CDBHCM_iad1dx - Physical standby database 
                      Transport Lag:      0 seconds (computed 0 seconds ago)
                      Apply Lag:          0 seconds (computed 1 second ago)
      CDBHCM_phx5s - Physical standby database (receiving current redo)
                        Transport Lag:      1 second (computed 1 second ago)
                        Apply Lag:          2 seconds (computed 1 second ago)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 47 seconds ago)

Definizione dei servizi di database basati su ruoli per il database in standby futuro

Aggiungere i servizi di database basati sui ruoli che l'applicazione PeopleSoft utilizzerà quando il database secondario OCI ricoprirà il ruolo PRIMARY.

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