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:@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 derivanti dall'uso 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 replicatoconfigdal 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 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 nell'infrastruttura OCI devono essere della 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 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 nell'ambiente cloud.
Lo scenario seguente è un esempio reale di riferimento. La home DB on premise è la 19.6 e la home DB OCI è la 19.11.
- Eseguire il comando
$ORACLE_HOME/OPatch/opatch lspatchesper identificare le patch installate negli ambienti di origine e di destinazione.$ORACLE_HOME/OPatch/opatch lspatchesDi seguito è riportato l'output di questo esempio.
Patch in locale di Oracle home DB Patch Oracle HOME DB su OCI 30676209;LNX64-20.1-RAC L'ECCEZIONE ORA-07445 HA RILEVATO IL DUMP CORE [KSXPOSDIFQRY()+556]
30613937;IPCOR TOPO SERVICE FIX IP TYPE BUG IN IP SELECTION
30484981;AGGIORNAMENTO DELLA RELEASE DI OJVM: 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;AUMENTA _LM_RES_HASH_BUCKET E REVOCA LE MODIFICHE DAL BUG 29416368 FIX
30310195;DBSAT - VINCOLI DISABILITATI SEGNALATI PER LA PARTIZIONE STS_CHUNKS SU GSMADMIN_INTERNAL.SHARD_TS
32327201;RDBMS - DSTV36 UPDATE - TZDATA2020E
31335037;RDBMS - DSTV35 UPDATE - TZDATA2020A
30432118;RICHIESTA DI UNIONE SOPRA LE 19.0.0.0.0 PER I BUG 28852325 29997937
31732095;AGGIORNAMENTO PERL IN 19C DATABASE ORACLE HOME IN V5.32
32490416; PATCH BUNDLE JDK 19.0.0.0.210420
32399816;AGGIORNAMENTO DELLA RELEASE DI OJVM: 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à fisse nella nuova RU prima di installare l'aggiornamento RU (altrimenti causeranno conflitti). In questo esempio, le patch on-off vengono corrette nella release 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 19.11 RU 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 le altre patch che la home DB OCI ha a monte dell'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 - 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
È buona norma applicare patch a GI allo stesso livello della home DB. Quando devi applicare una patch alla home DB a un aggiornamento della release (RU) più recente, molte delle patch sono comuni a DB e GI e puoi utilizzare OPatchAuto contemporaneamente ad entrambe le home.