Configurare l'ambiente
Sono disponibili script per automatizzare alcuni dei passi. Questi script non automatizzano l'impostazione completa, pertanto è necessario completare i task 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
L'alias TNS è lo stesso nome nel database primario e secondario, pertanto le origini dati utilizzano la stessa stringa di connessione al database. Si risolve con un file tnsnames.ora
che non viene copiato in standby, quindi in ciascun sito è possibile avere contenuti tnsnames.ora
diversi. È possibile posizionarlo separatamente dalla configurazione del dominio WebLogic in un file system non replicato tra i siti. In alternativa, poiché fa parte della configurazione, è possibile memorizzarla anche in una cartella sotto la 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:@mypdbservice
The tnsnames.ora file in primary contains:
MYPDBSERVICE =
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=mypdbservice.example.com))
)
Connect string in data sources in secondary site:
jdbc:oracle:thin:@mypdbservice
The tnsnames.ora file in secondary:
MYPDBSERVICE =
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=mypdbservice.example.com))
)
Di seguito sono riportati i vantaggi derivanti dall'uso dell'alias TNS.
- Poiché la stessa stringa di connessione del database viene utilizzata nel dominio WebLogic
config
, non è necessario modificare la configurazione WebLogic dopo aver replicatoconfig
dal database primario al database in standby. - Poiché ogni sito punta solo al database locale, non esiste alcun rischio di cross connect dal livello intermedio al database remoto.
Se non si utilizza già questo approccio nel sistema WebLogic Server primario, eseguire i passi riportati di seguito per utilizzare un alias TNS nelle origini dati.
Configurare la rete
Configura Oracle Data Guard
Informazioni sulla versione del database e sul livello di patch
La Oracle home nel database in locale e il database in standby in OCI devono avere la stessa versione e allo stesso livello di patch. È possibile ottenere questo scopo nei modi riportati 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 del 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, dovrai 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 esempio reale di riferimento. La home DB in locale è 19.6 e la home DB OCI è 19.11.
- Eseguire il comando
$ORACLE_HOME/OPatch/opatch lspatches
per identificare le patch installate sia nell'ambiente di origine che in quello di destinazione.$ORACLE_HOME/OPatch/opatch lspatches
Di seguito viene fornito l'output dell'esempio riportato di seguito.
Patch della Oracle home DB in locale Patch DB Oracle HOME su OCI 30676209;LNX64-20.1-RAC ASM HIT ORA-07445 ECCEZIONE RILEVATA CORE DUMP [KSXPOSDIFQRY()+556]
30613937;IPCOR TOPO SERVICE FIX IP TYPE BUG IN IP SELECTION
30484981;AGGIORNAMENTO VERSIONE OEMVM: 19.6.0.0.200114 (30484981)
30489227;OCW RELEASE UPDATE 19.6.0.0.0 (30489227)
30557433;Aggiornamento della release del database: 19.6.0.0.200114 (30557433)
29780459;AUMENTARE _LM_RES_HASH_BUCKET E RIPRISTINARE LE MODIFICHE DALLA CORREZIONE DEL BUG 29416368
30310195;DBSAT HA SEGNALATO VINCOLI DISABILITATI PER IL PARTIZIONAMENTO ORIZZONTALE STS_CHUNKS SU GSMADMIN_INTERNAL.SHARD_TS
32327201;RDBMS - AGGIORNAMENTO DSTV36 - TZDATA2020E
31335037;RDBMS - AGGIORNAMENTO DSTV35 - TZDATA2020A
30432118;RICHIESTA DI UNIONE SUPERIORE A 19.0.0.0.0 PER I BUG 28852325 29997937
31732095;AGGIORNA PERL IN 19C DATABASE ORACLE HOME A V5.32
32490416;PATCH BUNDLE JDK 19.0.0.0.210420
32399816;AGGIORNAMENTO VERSIONE OEMVM: 19.11.0.0.210420 (32399816)
32579761;OCW RELEASE UPDATE 19.11.0.0.0 (32579761)
32545013;Aggiornamento della release del database: 19.11.0.0.210420 (32545013)
- Analisi delle patch esistenti: individuazione delle patch singole, verifica se sono già state corrette nelle nuove patch RU o se sono necessarie nuove patch sovrapposte, determina quali patch devono essere disinstallate, individua i file delle patch appropriati per RU e così via.
- In base all'analisi, disinstallare le patch singole già corrette nella nuova RU prima di installare l'aggiornamento dell'IF (altrimenti, causeranno conflitti). In questo esempio, le patch on-off vengono corrette nella versione 19.11, pertanto è necessario eseguire il rollback delle patch prima di installare la RU 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
- Individuare, scaricare e installare le patch RU. In questo esempio, le patch RU 19.11 si trovano nella patch combo 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)
- Individuare, scaricare e installare gli overlay, le singole e altre patch applicate dalla home DB OCI a monte dell'IF. 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
- Eseguire un'analisi simile per le patch GI.
Nota:
- 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 dalla versione 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
È consigliabile applicare le patch a GI allo stesso livello della home DB. Una volta che è necessario applicare una patch alla home DB per un aggiornamento della release (RU) più recente, molte delle patch sono comuni per DB e GI e è possibile utilizzare OPatchAuto
in entrambe le home contemporaneamente.