Configurare l'ambiente

Impostare il sistema secondario in OCI e configurarlo come standby del sistema on premise primario.

Sono disponibili script per automatizzare alcuni passi. Questi script non automatizzano la configurazione completa, quindi è necessario completare le attività ed è possibile utilizzare gli script quando vi si fa riferimento.

Andare a Scarica codice per il collegamento per scaricare gli script a cui si fa riferimento nel documento.

Preparare le origini dati WebLogic nel data center primario

Esistono diversi approcci che è possibile utilizzare per la stringa di connessione al database delle origini dati WebLogic in una topologia di disaster recovery, ad esempio stringa doppia, stringhe di connessione diverse e alias TNS. Per ulteriori dettagli e per il confronto tra i diversi approcci, consultare il manuale Oracle Fusion Middleware Disaster Recovery Guide. L'alias TNS verrà utilizzato perché richiede una configurazione una tantum. L'uso di un alias TNS significa che non sarà necessario modificare la configurazione WebLogic ogni volta che la si copia nel secondario. L'uso di un alias TNS nelle origini dati GridLink è supportato avviando FMW versione 12.2.1.3.

L'alias TNS è lo stesso nome nel database primario e secondario; pertanto, le origini dati utilizzano la stessa stringa di connessione del database. Viene risolto con un file tnsnames.ora che non viene copiato in standby, quindi è possibile avere contenuto tnsnames.ora diverso in ogni sito. È possibile posizionarla separatamente dalla configurazione del dominio WebLogic in un file system che non viene replicato tra i siti. In alternativa, poiché fa parte della configurazione, è anche possibile memorizzarla in una cartella nella configurazione del dominio. In questo caso, assicurarsi di escludere tale cartella quando si copia la configurazione del dominio dal database primario al database in standby. Ogni sito risolverà l'alias TNS con la stringa di connessione appropriata in ogni sito, puntando solo al database locale. Ad esempio: 

Connect string in data sources in primary site:
jdbc:oracle:thin:@soapdb

The tnsnames.ora file in primary contains:
SOAPDB =
(DESCRIPTION=
 (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=soapdb.example.com))
)

Connect string in data sources in secondary site:
jdbc:oracle:thin:@soapdb
The tnsnames.ora file in secondary: 
SOAPDB =
(DESCRIPTION=
 (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=soapdb.example.com))
)

Di seguito sono riportati i vantaggi dell'utilizzo dell'alias TNS:

  • Poiché la stessa stringa di connessione al database viene utilizzata nel dominio WebLogic config, non è necessario modificare la configurazione WebLogic dopo aver replicato config dal database primario al database in standby.
  • Poiché ogni sito punta solo al database locale, non vi è alcun rischio di cross connect dal livello intermedio al database remoto.

Se non si utilizza già questo approccio nel sistema SOA primario, eseguire le seguenti operazioni per utilizzare un alias TNS nelle origini dati.

  1. Creare la cartella tns negli host di livello intermedio principali:

    Questa cartella deve essere leggibile dall'utente Oracle e inserita in un file system non replicato tra i siti.

    Dato che la cartella tns fa parte della configurazione, puoi anche crearla sotto la cartella di configurazione condivisa da tutti i server. In tal caso, tuttavia, assicurarsi di escludere la cartella tns quando si copia la configurazione del dominio dal database primario al database in standby o si aggiorna tnsnames.ora nel sistema in standby, dopo un failover o uno switchover, per puntare al database secondario. 

    [oracle@host3 ~]$ mkdir -p /home/oracle/tnsnames_dir
[oracle@host4 ~]$ mkdir -p /home/oracle/tnsnames_dir
  2. Creare un file tnsnames.ora nella directory con l'alias TNS che verrà utilizzato nelle origini dati, come mostrato nell'esempio.
    Oracle consiglia di immettere la stringa in una singola riga.
    SOAPDB = 
(DESCRIPTION=
  (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=dbhost-scan.example.com)(PORT=1521))
  )
  (CONNECT_DATA=(SERVICE_NAME= soapdb.example.com))
)
  3. Specificare la proprietà oracle.net.tns_admin che punta alla posizione della directory del file tnsnames.ora. Utilizzare uno dei metodi riportati di seguito.

    • Opzione 1: impostare la proprietà come proprietà di connessione all'origine dati. Oracle consiglia questo metodo.

      1. Specificare la proprietà oracle.net.tns_admin=tns_directory nella configurazione dell'origine dati.

        Per specificare questa proprietà nella console di amministrazione WebLogic, andare a Servizi, fare clic su Origini dati, selezionare un'origine dati dalla lista, fare clic su Connection pool, quindi aggiungerla alla casella di testo Properties. Ripetere questo passo per ogni origine dati.

        Ad esempio: oracle.net.tns_admin=/home/oracle/tnsnames_dir

      2. Specificare questa proprietà nella protezione OPSS per memorizzare i file jps-config-jse.xml e jps-config.xm disponibili nella cartella $ASERVER_HOME/config/fmwconfig.

        Per modificare questi file jps, modificarli e aggiungere la proprietà oracle.net.tns_admin dopo la proprietà jdbc.url. Di seguito sono riportati alcuni esempi. 

        …
<property name="jdbc.url" value="jdbc:oracle:thin:@soaedg"/>
<property name="oracle.net.tns_admin" value="tns_directory"/>
…

        Nota

        Questa proprietà si applica al file specifico (origine dati, file jps) in cui è specificata.

    • Opzione 2: impostare la proprietà come proprietà di sistema java.

      1. Specificare la proprietà di sistema -Doracle.net.tns_admin=tns_directory in cui tns_directory è la posizione della directory del file tnsnames.ora.

        Per impostarla come proprietà java per i server, modificare i seguenti file:
        • $ASERVER_HOME/bin/setUserOverrides.sh and
        • $MSERVER_HOME/bin/setUserOverrides.sh (questo file non è condiviso). Pertanto, è necessario modificare il file in tutti gli host di livello intermedio SOA.)

      2. Aggiungere il seguente contenuto a questi file: 

        # For using tns alias in the datasources 
export EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Doracle.net.tns_admin=/home/oracle/tnsnames_dir

        Nota

        Questa proprietà si applica a tutte le origini dati e ai file jps in Oracle WebLogic Server. Prima di eseguire alcuni comandi WLST e la Configurazione guidata, questo approccio richiede l'impostazione della proprietà nell'ambiente.
        • Prima di eseguire WLST, impostare la proprietà nella variabile di ambiente WLST_PROPERTIES.
        • Prima di eseguire la configurazione guidata, aggiungere la proprietà alla variabile di ambiente JVM_ARGS dello script config_internal.sh.
      3. Opzione 3: impostare la proprietà nell'URL jdbc.

        Specificare la posizione del file tnsnames.ora come parte della stringa di connessione nelle origini dati e nei file jps: 

        jdbc:oracle:thin:@alias?TNS_ADMIN=tns_directory

      Nota

      Questa proprietà si applica al file specifico (origine dati, file jps) in cui è specificata.

      È possibile utilizzare questo metodo con il driver JDBC 18.3 e versioni successive. Ciò si applica a Fusion Middleware 12.2.1.4 (che utilizza il driver JDBC 19.3) e versioni successive.

  4. Utilizzare l'alias nell'URL della definizione dell'origine dati sostituendo la stringa di connessione con l'alias.
    jdbc:oracle:thin:@soapdb
    Modificare i seguenti file:
    • Nei file di origine dati, in $ASERVER_HOME/config/jdbc/
    • Nei file jps-config.xml e jps-config-jse.xml, in $ASERVER_HOME/config/fmwconfig/
    Per modificare le origini dati, è possibile utilizzare la console di amministrazione di Oracle WebLogic Server, ma è necessario modificare manualmente i file jps-config xml. È possibile utilizzare lo script update_dbconnect.sh per eseguire la sostituzione in tutti i file menzionati.

    Andare a Scarica codice per il collegamento per scaricare lo script.

  5. Riavviare ogni Oracle WebLogic Server nel dominio.
    1. Arrestare tutti i server WebLogic nel dominio primario (server di amministrazione e server gestiti).
    2. Avviare il server di amministrazione nel dominio principale.
    3. Una volta eseguito il server di amministrazione, avviare i server gestiti.
    4. Verificare che le connessioni siano stabilite correttamente con il database.
  6. Procedure ottimali aggiuntive: quando si utilizza un Oracle Database 12c o versioni successive, i valori di configurazione dell'host e della porta di Oracle Notification Service (ONS) non sono necessari nelle origini dati GridLink.
    La lista Oracle Notification Service viene ottenuta automaticamente dal database dal driver client. Oracle consiglia di utilizzare questa funzione invece di fornire l'indirizzo di scansione o la lista dei nodi Oracle RAC nella configurazione ONS di ogni origine dati. Assicurarsi che FAN sia abilitato e che la proprietà ONS nodes sia vuota in ogni origine dati.
    1. Aprire la console di amministrazione di Oracle WebLogic Server.
    2. Andare a Servizi, quindi a Origini dati. Selezionare il nome dell'origine dati, quindi Configurazione e ONS.
    3. Verificare che l'elenco dei nodi ONS sia vuoto.

Configurare la rete

È necessaria la connettività tra la rete on-premise primaria e la rete Oracle Cloud Infrastructure (OCI) secondaria. Oracle consiglia di utilizzare Oracle Cloud Infrastructure FastConnect, che consente di connettersi direttamente alla rete cloud virtuale OCI tramite una connessione dedicata, privata e a larghezza di banda elevata. Scegliere una velocità della porta appropriata in base alla quantità di dati. In alternativa, puoi utilizzare la VPN da sito a sito, sebbene fornisca una larghezza di banda inferiore e latenza, jitter e costi variabili.
  1. Crea la VCN e le subnet nel compartimento OCI come definito in Determina le risorse necessarie su OCI. Configura Oracle Cloud Infrastructure FastConnect (o VPN da sito a sito) per consentire la comunicazione tra la tua rete on premise e la VCN. Per informazioni, vedere FastConnect e VPN Site-to-Site.
  2. Creare le regole di rete necessarie in OCI e nel firewall on premise e configurare l'origine, le destinazioni, i protocolli e le porte, come mostrato nella tabella.

    Si presume che tutto il traffico sia abilitato all'interno di ogni subnet.

    Per informazioni sulle regole di sicurezza di rete, consultare la documentazione OCI.

    Origine Obiettivo Protocollo e porta Utilizzo
    Rete in locale Subnet di livello intermedio OCI SSH (porta 22) Impostazione e ciclo di vita
    Rete in locale Subnet di livello Web OCI SSH (porta 22) Impostazione e ciclo di vita (quando in OCI si utilizza Oracle HTTP Server)
    Rete in locale Subnet di livello DB OCI SSH (porta 22) Impostazione e ciclo di vita
    Host DB in locale Subnet di livello DB OCI SQLNET (porta 1521) Per Oracle Data Guard redo transport
    Rete in locale Subnet di livello Web OCI HTTPS/HTTP (443, 80, 7001, 8888) Accesso ai servizi e alle console di amministrazione di Oracle SOA Suite
    Rete in locale Subnet di livello intermedio OCI HTTP (7001,7010,8001,8011,8021,9001) Per i controlli diretti a Oracle WebLogic Server
    Subnet di livello Web OCI Subnet di livello intermedio OCI HTTP (7001,7010,8001,8011,8021,9001) Per la connettività dai componenti del livello Web (OCI Load Balancer, Oracle HTTP Server) ai server WebLogic
    Subnet di livello intermedio OCI Subnet di livello DB OCI SQLNET (1521), ONS (6200) Per la connettività dal server WebLogic al database
    Subnet di livello intermedio OCI Subnet di livello fss OCI Per informazioni specifiche, vedere Configurazione delle regole di sicurezza VCN per lo storage di file. Per eseguire il MOUNT delle esportazioni del file system di storage di file OCI con NFS.
    Subnet di livello intermedio OCI Host di livello intermedio in locale SSH (porta 22) Per rsync
    Subnet di livello DB OCI Host DB in locale SQLNET (1521) Per Oracle Data Guard redo transport
    Subnet di livello intermedio OCI Subnet di livello Web OCI HTTPS (443) Per i callback dall'applicazione al front-end

    Nota

    Puoi trovare il codice terraform per creare la VCN, le subnet e le regole di sicurezza in Scarica codice.

Configura Oracle Data Guard

Configurare Oracle Data Guard tra il database in locale primario e il database in standby in Oracle Cloud Infrastructure (OCI).
  1. Configura Oracle Data Guard tra un database primario in locale e uno in standby in OCI, come descritto in Hybrid Data Guard in Oracle Cloud Infrastructure.
    Per facilitare la configurazione di Oracle Data Guard, gli script sono disponibili in GitHub e vi viene fatto riferimento in Scarica codice.
  2. Verificare che l'impostazione di Oracle Data Guard sia corretta utilizzando l'interfaccia della riga di comando (DGMGRL) di Oracle Data Guard.
    DGMGRL> show configuration verbose
  3. Una volta completata la configurazione di Oracle Data Guard (passo 2), creare nel sistema DB OCI gli stessi servizi di database utilizzati nel sistema primario on premise. Configurare il servizio con il ruolo PRIMARY e con il ruolo SNAPSHOT_STANDBY.
    La configurazione del servizio con entrambi i ruoli consente all'avvio automatico del servizio da parte di DG Broker quando il database viene convertito in standby snapshot, cosa necessaria quando si desidera convalidare il sistema secondario senza eseguire uno switchover completo.
    Ad esempio, se il database primario utilizza il servizio di database soapdb.example.com per accedere al PDB, creare lo stesso servizio nel sistema DB OCI secondario. 
    srvctl add service -db $ORACLE_UNQNAME -service soapdb.example.com -preferred ORCL1,ORCL2 -pdb PDB1 -role "PRIMARY,SNAPSHOT_STANDBY"
srvctl modify service -db $ORACLE_UNQNAME -service soapdb.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT
srvctl config service -db $ORACLE_UNQNAME -service soapdb.example.com
  4. Se il servizio nel database primario è stato creato solo con il ruolo PRIMARY (impostazione predefinita), è possibile modificarlo per aggiungere il ruolo di standby snapshot.
    srvctl modify service -db $ORACLE_UNQNAME -s soapdb.example.com -role "PRIMARY,SNAPSHOT_STANDBY"
  5. Rivedere i criteri di Oracle Recovery Manager (RMAN) nel database primario per impedire l'eliminazione dei log di archivio prima che vengano applicati al database di standby.
    Assicurarsi di disporre della clausola applied on all standby nel criterio di eliminazione archivelog di RMAN, nei database primario e in standby.

Informazioni sulla versione del database e sul livello di patch

La Oracle home nel database in locale e il database in standby su OCI devono avere la stessa versione e allo stesso livello di patch. A tale scopo, è possibile effettuare le operazioni riportate di seguito.

  • Quando si sceglie l'immagine software del database durante il provisioning del sistema DB in OCI, selezionare Visualizza tutte le versioni e selezionare la stessa versione del database e lo stesso livello di set di patch del database in locale.
  • Se la versione della Oracle home del database di origine non è più disponibile in OCI per il provisioning, sarà necessario applicare le patch all'ambiente di origine allo stesso livello di patch del database della home del database nell'ambiente cloud.

Il seguente scenario è un vero esempio di riferimento. La home DB in locale è la versione 19.6 e la home DB OCI è la versione 19.11.

  1. Eseguire il comando $ORACLE_HOME/OPatch/opatch lspatches per identificare le patch installate negli ambienti di origine e di destinazione.
    $ORACLE_HOME/OPatch/opatch lspatches

    Di seguito è riportato l'output di questo esempio.

    Patch della Oracle home DB in locale Patch DB Oracle HOME su OCI

    30676209;LNX64-20.1-RAC ASM HIT ORA-07445 ECCEZIONE RILEVATA DURANTE IL DUMP CORE [KSXPOSDIFQRY()+556]

    30613937;IPCOR TOPO SERVICE FIX IP TYPE BUG NELLA SELEZIONE IP

    30484981;AGGIORNAMENTO DELLA RELEASE DI OJVM: 19.6.0.0.200114 (30484981)

    30489227;AGGIORNAMENTO DELLA RELEASE OCW 19.6.0.0.0 (30489227)

    30557433;Aggiornamento release del database : 19.6.0.0.200114 (30557433)

    29780459;AUMENTARE _LM_RES_HASH_BUCKET E ANNULLARE LE MODIFICHE DAL BUG 29416368 FIX

    30310195;VINCOLI DISABILITATI SEGNALATI DA DBSAT PER PARTIZIONAMENTO ORIZZONTALE STS_CHUNKS IL GSMADMIN_INTERNAL.SHARD_TS

    32327201;RDBMS - DSTV36 AGGIORNAMENTO - TZDATA2020E

    31335037;RDBMS - DSTV35 AGGIORNAMENTO - TZDATA2020A

    30432118;RICHIESTA DI UNIONE SOPRA 19.0.0.0.0 PER I BUG 28852325 29997937

    31732095;AGGIORNA PERL NELLA HOME ORACLE DEL DATABASE 19C ALLA VERSIONE 5.32

    32490416;PATCH DEL BUNDLE JDK 19.0.0.0.210420

    32399816;AGGIORNAMENTO DELLA RELEASE DI OJVM: 19.11.0.0.210420 (32399816)

    32579761;AGGIORNAMENTO DELLA RELEASE OCW 19.11.0.0.0 (32579761)

    32545013;Aggiornamento release del database : 19.11.0.0.210420 (32545013)
  2. Analizzare le patch esistenti: determinare quali sono le patch singole, verificare se sono già state corrette nelle nuove patch RU o se sono necessarie nuove patch sovrapposte, determinare quali di esse devono essere disinstallate, individuare i file di patch appropriati per l'aggiornamento release e così via.
  3. In base all'analisi, disinstallare le patch singole già corrette nel nuovo RU prima di installare l'aggiornamento RU (in caso contrario, causeranno conflitti). In questo esempio, le patch attive vengono corrette nella release 19.11, pertanto è necessario eseguire il rollback delle patch prima di installare l'aggiornamento release 19.11.
    30676209;LNX64-20.1-RAC  ASM HIT ORA-07445  EXCEPTION ENCOUNTERED  CORE DUMP [KSXPOSDIFQRY()+556]
30613937;IPCOR TOPO SERVICE  FIX IP TYPE BUG IN IP SELECTION
  4. Individuare, scaricare e installare le patch dell'aggiornamento release (RU). In questo esempio, le patch RU 19.11 si trovano nella patch combinata 32578973: COMBO OF OJVM RU COMPONENT 19.11.0.0.210420 + GI RU 19.11.0.0.210420 e sono le seguenti:
    32399816;OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816)  
32579761;OCW RELEASE UPDATE 19.11.0.0.0 (32579761)            
32545013;Database Release Update : 19.11.0.0.210420 (32545013)
  5. Individuare, scaricare e installare gli overlay, le patch singole e le altre patch di cui dispone la home DB OCI a monte dell'aggiornamento release (RU). Ad esempio: 
    29780459;INCREASE _LM_RES_HASH_BUCKET AND BACK OUT CHANGES FROM THE BUG 29416368 FIX
30310195;DBSAT REPORTED DISABLED CONSTRAINTS FOR SHARDING STS_CHUNKS ON GSMADMIN_INTERNAL.SHARD_TS
30432118;MERGE REQUEST ON TOP OF 19.0.0.0.0 FOR BUGS 28852325 (DSTV33 update) 29997937 (DSTV34 update)
31335037;RDBMS - DSTV35 UPDATE - TZDATA2020A
32327201;RDBMS - DSTV36 UPDATE - TZDATA2020E
32490416;JDK BUNDLE PATCH 19.0.0.0.210420
31732095;UPDATE PERL IN 19C DATABASE ORACLE HOME TO V5.32
  6. Eseguire un'analisi simile per le patch GI.

Nota

Questo esempio include solo la Oracle home RDBMS. L'applicazione di patch all'installazione GI in locale allo stesso livello di quella secondaria potrebbe non essere strettamente necessaria:
  • Dal punto di vista di Oracle Data Guard, non è strettamente necessario disporre delle stesse versioni GI nel database primario e in standby: Oracle Data Guard è completamente indipendente da qualsiasi elemento presente nel database, pertanto è possibile eseguire versioni diverse del sistema operativo, di Oracle Clusterware, dell'hardware o del software di storage su siti diversi senza alcuna restrizione in termini di versioni o tempo. (ID documento 1265700.1)
  • Indipendentemente da Oracle Data Guard, non è necessario disporre della stessa versione nelle versioni GI e RDBMS in un database RAC: a partire da 18c, la versione Oracle Grid Infrastructure (GI) /Clusterware (CRS) deve essere uguale o la versione più alta fino alla prima cifra nelle combinazioni possibili in qualsiasi momento. Ad esempio: Grid Infrastructure può trovarsi in 18.1.0.0 e Database può essere in 18.3.0.0. (ID documento 337737.1)

È buona norma applicare le patch a GI allo stesso livello della home DB. Dopo aver applicato la patch della home DB a un aggiornamento della release più recente (RU), molte delle patch sono comuni per DB e GI ed è possibile utilizzare OPatchAuto per entrambe le home contemporaneamente.