Configurare una soluzione DR con Oracle Autonomous Database

Configura una soluzione DR con Oracle Autonomous Database

Per garantire la continuità del business in caso di disastri, dovrai implementare una strategia di recupero da errori irreversibili per le tue applicazioni Oracle WebLogic Suite. Questa soluzione offre protezione dei dati e consente di utilizzare Oracle Autonomous Database per passare rapidamente al sistema in standby con una perdita minima di dati e produttività.

È possibile impostare e gestire un sistema di disaster recovery che utilizza Oracle Autonomous Database come database per Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace o qualsiasi altro servizio di livello intermedio Oracle Cloud Infrastructure (OCI) che utilizza Oracle Fusion Middleware.

Oracle Autonomous Database Serverless e Oracle Exadata Database Service on Dedicated Infrastructure offrono una funzione di standby snapshot. Ciò consente di aprire temporaneamente il database in standby per la lettura-scrittura. Quando si converte il database di standby in uno standby snapshot, è completamente aggiornabile. Continua a ricevere i dati redo dal database di origine remoto (in modo da essere ancora protetti da DR), ma non applica redo fino a quando non viene convertito in standby fisico. Tutte le modifiche eseguite in un database di standby snapshot vengono annullate quando viene nuovamente convertito in standby fisico. Utilizzare questa funzione per eseguire il provisioning del sistema di livello intermedio nella standby region. È inoltre possibile utilizzare questa funzione durante il ciclo di vita del sistema DR per convalidare il sistema in standby senza eseguire uno switchover completo.

Oltre alla funzione di standby snapshot, Oracle Autonomous Database Serverless fornisce copie aggiornabili remote. Ciò fornisce funzionalità equivalenti alla tradizionale funzionalità del database di standby snapshot Oracle Data Guard, ma utilizza un database aggiuntivo. La copia aggiornabile remota viene gestita singolarmente e separatamente dal database di standby Oracle Autonomous Data Guard. Quando si utilizza Oracle Autonomous Database Serverless, è possibile utilizzare una copia aggiornabile remota anziché un database di standby snapshot per eseguire il provisioning del sistema di livello intermedio nell'area secondaria o per eseguire task in standby come test, apertura per convalide, applicazione di patch e così via. Tuttavia, i database clone in standby e aggiornabili utilizzano wallet di connessione diversi e le relative stringhe di connessione devono essere gestite in modo appropriato per eseguire questi task.

Prima di iniziare

Esistono più brief tecnici su Oracle Maximum Availability Architecture (MAA) che descrivono come impostare un sistema di recupero da errori irreversibili per Oracle WebLogic Server for Oracle Cloud Infrastructure e Oracle SOA Suite su Marketplace quando questi sistemi middleware utilizzano Oracle Base Database Service.

Le topologie DR Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite su Marketplace e Oracle Fusion Middleware utilizzano un modello attivo-passivo. Il sistema primario è un data center Oracle Cloud Infrastructure (OCI) e un sistema secondario in un data center OCI diverso e remoto.

Per ulteriori dettagli e topologie per ciascun caso, consultare gli argomenti riportati di seguito.

I documenti di cui sopra forniscono dettagli approfonditi, procedure di impostazione e gestione, nonché molte altre considerazioni, per Oracle WebLogic Server for Oracle Cloud Infrastructure e Oracle SOA Suite su Marketplace.

Oltre ai brief tecnici, assicurati di avere familiarità con i concetti e l'amministrazione di Oracle Cloud Infrastructure (OCI), tra cui networking, istanze di computazione, bilanciamento del carico e Oracle Autonomous Database prima di procedere con l'analisi e i passi descritti in questa playbook.

I passi e gli esempi di questa guida vengono verificati con Oracle WebLogic Server per OCI e Oracle SOA Suite su Marketplace per i seguenti scenari:

Oracle Autonomous Data Guard su Oracle Exadata Database Service on Dedicated Infrastructure, utilizzando la funzione Snapshot Standby per l'impostazione del disaster recovery.
Oracle Autonomous Data Guard su Oracle Autonomous Database Serverless, utilizzando la funzione Standby snapshot per l'impostazione del disaster recovery.
Oracle Autonomous Data Guard su Oracle Autonomous Database Serverless, utilizzando Remote Refreshable Clones per l'impostazione del disaster recovery.

La maggior parte dei passi sono comuni per i tre scenari. Solo alcuni passi differiscono e sono specifici per ogni caso.

Non è difficile regolare i passi su qualsiasi sistema Oracle WebLogic Server o Oracle Fusion Middleware che utilizza Oracle Autonomous Database.

Architettura

Questo diagramma dell'architettura mostra la topologia del sistema di disaster recovery (DR) per gli approcci utilizzati in questa guida. Tutte le informazioni su runtime, configurazione e metadati presenti nel database primario vengono replicate dall'area 1 all'area 2 con Oracle Autonomous Data Guard. Le topologie DR Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite su Marketplace e Oracle Fusion Middleware utilizzano un modello attivo-passivo. Il sistema primario è un data center Oracle Cloud Infrastructure (OCI) e un sistema secondario in un data center OCI diverso e remoto.

La configurazione del dominio Oracle WebLogic viene replicata utilizzando una directory intermedia Oracle Cloud Infrastructure File Storage (OCI File Storage) nell'area primaria, che viene replicata in una directory intermedia OCI File Storage nell'area secondaria. Quindi, la configurazione viene copiata nella directory del dominio reale nella directory secondaria. La copia diretta del dominio presenta rischi che vengono evitati utilizzando una directory intermedia. Poiché le copie dei file sono operazioni non transazionali, viene eseguita una prima copia in una directory di staging. I file vengono verificati in questa directory intermedia e quindi trasferiti nel vero dominio Oracle WebLogic (finale).

Descrizione dell'illustrazione wls-dr-adb.png

wls-dr-adb-oracle.zip

La topologia è tipica degli ambienti di recupero da errori irreversibili di Oracle WebLogic Server, Oracle SOA o Oracle Fusion Middleware in OCI. Per il provisioning del livello intermedio in standby e per le operazioni del ciclo di vita come il test secondario, è necessario convertire il database in standby Oracle Autonomous Database in un database in standby snapshot o utilizzare una copia aggiornabile remota.

Quando si utilizza una copia aggiornabile remota, esiste un "database ausiliario" (una copia aggiornabile in un'area remota) per il provisioning iniziale e per le operazioni di test e convalida nel database secondario. In questo caso, il livello intermedio secondario viene configurato con origini dati che devono essere reimpostate sull'indirizzo in standby in caso di eventi di switchover e failover.

Questa architettura supporta i componenti elencati di seguito.

Regione
Un'area Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, definiti domini di disponibilità. Le regioni sono indipendenti da altre regioni e grandi distanze possono separarle (in tutti i paesi o anche in continenti).
Dominio di disponibilità
I domini di disponibilità sono data center standalone e indipendenti all'interno di un'area geografica. Le risorse fisiche in ciascun dominio di disponibilità sono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono l'infrastruttura, ad esempio l'alimentazione o il raffreddamento o la rete interna del dominio di disponibilità. Pertanto, un errore in un dominio di disponibilità non dovrebbe influire sugli altri domini di disponibilità nell'area.
Dominio di errore
Un dominio di errore è un raggruppamento di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità dispone di tre domini di errore con alimentazione e hardware indipendenti. Quando distribuisci risorse su più domini di errore, le tue applicazioni possono tollerare errori fisici del server, manutenzione del sistema e errori di alimentazione all'interno di un dominio di errore.
Rete cloud virtuale (VCN) e subnet
Una VCN è una rete personalizzabile e definita dal software configurata in un'area Oracle Cloud Infrastructure. Analogamente alle reti di data center tradizionali, i VCN offrono il controllo completo sull'ambiente di rete. Una VCN può avere più blocchi CIDR non sovrapposti che puoi modificare dopo aver creato la VCN. Puoi segmentare una VCN nelle subnet che possono essere definite nell'area o in un dominio di disponibilità. Ogni subnet è composta da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet nella VCN. Puoi modificare le dimensioni di una subnet dopo la creazione. Una subnet può essere pubblica o privata.
Load balancer
Il servizio Oracle Cloud Infrastructure Load Balancing offre la distribuzione automatica del traffico da un unico punto di accesso a più server nel back-end.
Dominio Oracle WebLogic
Un dominio è l'unità di amministrazione di base per le istanze del server WebLogic. Un dominio è costituito da una o più istanze del server WebLogic (e dalle relative risorse associate) gestite con un singolo server di amministrazione. Il dominio Oracle WebLogic è configurato seguendo le migliori prassi su Oracle Maximum Availability Architecture (MAA) per l'alta disponibilità.
Gateway di instradamento dinamico (DRG)
DRG è un router virtuale che fornisce un percorso per il traffico di rete privato tra VCN nella stessa area, tra una VCN e una rete esterna all'area, come una VCN in un'altra area Oracle Cloud Infrastructure, una rete in locale o una rete in un altro provider cloud.
Lista di sicurezza
Per ogni subnet, puoi creare regole di sicurezza che specifichino l'origine, la destinazione e il tipo di traffico che deve essere consentito all'interno e all'esterno della subnet.
Storage di file di Oracle Cloud Infrastructure
Il servizio di storage di file di Oracle Cloud Infrastructure fornisce un file system di rete duraturo, scalabile, sicuro e di livello enterprise. Puoi connetterti a un file system del servizio di storage di file da qualsiasi istanza Bare Metal, virtual machine o container nella tua rete VCN. Il servizio di storage di file supporta il protocollo Network File System versione 3.0 (NFSv3). Il servizio supporta il protocollo NLM (Network Lock Manager) per la funzionalità di blocco dei file.

Oracle Cloud Infrastructure File Storage utilizza lo storage replicato a 5 vie, posizionato in domini di errore diversi, per fornire ridondanza per la protezione dei dati resilienti. I dati sono protetti con la codifica di cancellazione. Il servizio è stato progettato per soddisfare le esigenze di applicazioni e utenti che richiedono un file system aziendale in una vasta gamma di casi d'uso.
Autonomous Database
Oracle Autonomous Database è un ambiente di database preconfigurato e completamente gestito che puoi utilizzare per l'elaborazione delle transazioni e i carichi di lavoro di data warehousing. Non è necessario configurare o gestire hardware né installare software. Oracle Cloud Infrastructure gestisce la creazione del database, nonché il backup, l'applicazione di patch, l'aggiornamento e l'ottimizzazione del database.
Oracle Autonomous Database on Dedicated Exadata Infrastructure
Oracle Autonomous Database on Dedicated Exadata Infrastructure è un Oracle Autonomous Database con un cloud di database privato nel cloud pubblico. Grazie al database dedicato puoi ottenere un servizio di computazione, storage, rete e database completamente dedicato che garantisce i massimi livelli di sicurezza, isolamento e gestione del controllo.
Oracle Autonomous Database Serverless

Oracle Autonomous Database Serverless è un Oracle Autonomous Database. Hai un database completamente elastico in cui Oracle gestisce autonomamente tutti gli aspetti del ciclo di vita del database, dal posizionamento del database al backup e agli aggiornamenti.
Data Guard
Oracle Data Guard offre un set completo di servizi che consente di creare, gestire, gestire e monitorare uno o più database in standby per consentire ai database Oracle di produzione di rimanere disponibili senza interruzioni. Oracle Data Guard gestisce questi database in standby come copie del database di produzione. Quindi, se il database di produzione non è più disponibile a causa di un'indisponibilità pianificata o non pianificata, Oracle Data Guard può passare qualsiasi database in standby al ruolo di produzione, riducendo al minimo i tempi di inattività associati all'indisponibilità.
Oracle Autonomous Data Guard
Oracle Autonomous Data Guard consente a un database di standby (peer) di fornire protezione dei dati e disaster recovery per l'istanza di Autonomous Database. Fornisce un set completo di servizi che creano, mantengono, gestiscono e monitorano uno o più database in standby per consentire ai database Oracle di produzione di rimanere disponibili senza interruzioni. Oracle Data Guard gestisce questi database in standby come copie del database di produzione. Quindi, se il database di produzione non è più disponibile a causa di un'indisponibilità pianificata o non pianificata, è possibile passare da qualsiasi database in standby al ruolo di produzione, riducendo al minimo i tempi di inattività associati all'indisponibilità.
Standby snapshot
Un database in standby snapshot è un database in standby completamente aggiornabile creato convertendo un database in standby fisico in un database in standby snapshot.

Un database in standby snapshot riceve e archivia, ma non applica, i dati redo da un database primario. I dati redo ricevuti dal database primario vengono applicati una volta convertito di nuovo un database in standby snapshot in un database in standby fisico, dopo aver eliminato tutti gli aggiornamenti locali del database in standby snapshot.
Copia aggiornabile
Oracle Autonomous Database fornisce la duplicazione in cui è possibile scegliere di creare una copia completa dell'istanza attiva, creare una copia dei metadati o creare una copia aggiornabile. Con una copia aggiornabile il sistema crea una copia che può essere facilmente aggiornata con le modifiche apportate al database di origine.

Considerazioni per il livello intermedio

Tutte le considerazioni riportate in Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery e SOA Suite su Oracle Cloud Infrastructure Marketplace Disaster Recovery per il livello intermedio sono applicabili negli scenari Oracle Autonomous Database descritti in questo documento.

Considerare i seguenti aspetti per il livello intermedio:

Indirizzo front-end
L'accesso dai client al sistema Oracle WebLogic Server deve essere indipendente dal sito utilizzato come sito principale. A tale scopo, il nome dell'indirizzo front-end utilizzato per accedere al sistema deve essere univoco e puntare sempre al sistema principale al momento. In genere, questo nome viene denominato front-end o URL univoco virtuale.

È possibile riutilizzare l'indirizzo del nome host frontend del sistema esistente come frontend virtuale per la protezione da errori irreversibili. Ad esempio, se il sistema originale ha mywebapps.example.com come URL univoco per il sistema primario, è possibile rimappare lo stesso nome host virtuale all'IP del load balancer del secondo sito dopo uno switchover o un failover.

Utilizzare un servizio DNS (Domain Name System) appropriato per mappare il nome front-end su entrambi i siti. Ad esempio, (servizio Oracle Cloud Infrastructure DNS, altra risoluzione DNS commerciale, DNS locale o host locali).
Prefisso nome istanza
Fornire un valore Instance Name Prefix quando si esegue il provisioning di Oracle WebLogic Server per OCI o di Oracle SOA Suite su Marketplace. Questa proprietà viene utilizzata per creare i nomi di tutte le risorse, tra cui: il nome del dominio del server WebLogic, il nome del cluster, i nomi del server WebLogic, i nomi host delle VM e così via.

Impostare Instance Name Prefix sullo stesso valore nei sistemi Oracle WebLogic Server primari e secondari, in modo che entrambi i sistemi abbiano lo stesso nome per le risorse Oracle WebLogic. L'uso dello stesso nome garantisce la coerenza ed è necessario per il recupero dei messaggi JMS e TLogs. Semplifica inoltre le personalizzazioni e le operazioni in entrambi i siti.

Puoi usare la stessa istanza di Instance Name Prefix in più istanze nella stessa tenancy di Oracle Cloud, purché tu li crei in aree o compartimenti diversi. Ogni istanza viene visualizzata solo nell'area e nel compartimento specifici.

Il processo di provisioning di Oracle SOA Suite su Marketplace offre una funzione facoltativa che consente di configurare nomi personalizzati per il dominio, il cluster, il server di amministrazione, il prefisso del server gestito e così via. In tal caso, i nomi non provengono da Instance Name Prefix. Vengono invece forniti i valori. È possibile utilizzare questa funzione nella topologia di recupero da errori irreversibili descritta in questo documento, purché i nomi personalizzati forniti siano gli stessi nei sistemi primario e in standby.
File personalizzati
La maggior parte della configurazione del dominio Oracle WebLogic Server for OCI utilizzata da WebLogic Cloud viene sincronizzata inizialmente tra i siti con le considerazioni riportate di seguito.

Ogni sistema WebLogic gestisce gli URL JDBC originali utilizzati per la connessione al database locale, anche dopo il completamento dell'impostazione di DR. Solo il prefisso dello schema viene modificato in modo che entrambe le posizioni puntino agli stessi schemi (schemi primari).

La funzione Infrastruttura di dominio WebLogic distribuisce automaticamente la configurazione sotto la directory weblogic_domain_name/config agli altri nodi sullo stesso dominio.

Le distribuzioni di applicazioni personalizzate (file di avvertenza, piani di distribuzione e così via) e tutto ciò che risiede nella directory del dominio di Oracle WebLogic Administration Server (tranne i dati temporanei) vengono inizialmente sincronizzati tra i siti utilizzando le procedure descritte in questo documento. Se Oracle WebLogic Administration Server utilizza dati che risiedono in altri nodi o al di fuori della directory del dominio, è necessario copiarlo manualmente nella posizione secondaria. Ulteriori dettagli sulla replica della configurazione vengono forniti in un secondo momento.

Considerazioni per standby snapshot su Oracle Autonomous Database Serverless

Quando si implementa questa soluzione, considerare quanto segue quando si abilita Snapshot Standby in un database Oracle Autonomous Database Serverless.

Limite di tempo per lo standby snapshot in un'infrastruttura serverless
Quando uno standby snapshot in Oracle Autonomous Database Serverless non viene riconnesso entro 48 ore, lo standby snapshot si riconnette automaticamente al database di origine.
Conversione in peer di disaster recovery
Oracle consiglia di convertire un standby snapshot in un peer di recupero da errori irreversibili non appena si esegue l'operazione che richiede l'apertura del database in standby per le operazioni di lettura-scrittura. Quando si esegue la conversione in un peer di ripristino di emergenza, le modifiche accumulate dal database di origine vengono applicate al peer. Se il peer per il recupero da errori irreversibili viene aperto come standby dello snapshot per un periodo di tempo più lungo, presumendo che ci siano modifiche in corso sul database primario durante questo periodo di tempo, il ripristino da un peer per il recupero da errori irreversibili richiede più tempo.
Implicazioni sui costi dello standby snapshot in Oracle Autonomous Database Serverless
L'uso della CPU in standby snapshot viene fatturato in base al conteggio delle CPU di base e a qualsiasi uso aggiuntivo della CPU se è abilitata la scala automatica della computazione. Il numero di CPU di base viene specificato dal numero di ECPU (OCPU se il database utilizza le OCPU), come indicato nel campo Conteggio ECPU o Conteggio OCPU nella console Oracle Cloud Infrastructure.

L'uso dello storage in standby dello snapshot viene fatturato in base allo storage del database in standby dello snapshot più 1 volta lo storage del database primario di origine.

Per ulteriori dettagli, vedere Informazioni sui database in standby snapshot di disaster recovery.

Considerazioni per standby snapshot su Oracle Autonomous Database on Dedicated Exadata Infrastructure

Quando si implementa questa soluzione, considerare quanto segue quando si abilita Snapshot Standby su Oracle Autonomous Database on Dedicated Exadata Infrastructure.

Limite di tempo per lo standby snapshot in un'infrastruttura dedicata
Quando uno standby snapshot in Oracle Autonomous Database on Dedicated Exadata Infrastructure non viene convertito in standby fisico entro 7 giorni, lo standby snapshot viene convertito automaticamente in standby fisico.
Conversione in un database in standby fisico
Oracle consiglia di convertire un standby snapshot in uno standby fisico non appena si esegue l'operazione che richiede l'apertura del database in standby per le operazioni di lettura-scrittura. Quando si esegue la conversione del database in standby fisico, le modifiche accumulate dal database di origine vengono applicate al database in standby. Se si mantiene il database in standby aperto come standby snapshot per un periodo più lungo, presumendo che ci siano modifiche in corso sul database primario durante questo periodo di tempo, la conversione in standby fisico richiederà più tempo.
Servizi di database durante la conversione in standby snapshot
In Oracle Autonomous Database on Dedicated Exadata Infrastructure, la finestra di dialogo "Converti in standby snapshot" visualizza due opzioni:
- Usa nuovi servizi di database: selezionare questa opzione per connettersi a un database in standby snapshot utilizzando nuovi servizi attivi solo in modalità standby snapshot.
- Usa servizi di database primario: selezionare questa opzione se si desidera connettersi al database di standby snapshot utilizzando gli stessi servizi del database primario.
Per l'impostazione del disaster recovery, utilizzare l'opzione Usa servizi di database primario quando si converte lo standby in standby fisico. In questo modo, il nome dell'alias di connessione configurato da Oracle WebLogic Server nel livello intermedio secondario è coerente con quello primario.

Per ulteriori dettagli, vedere Informazioni su Autonomous Data Guard.

Considerazioni per le copie aggiornabili remote su Oracle Autonomous Database Serverless

Si consideri quanto segue quando si utilizza una copia aggiornabile di Oracle Autonomous Database Serverless per eseguire il test e la convalida di un sistema secondario Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace o Oracle Fusion Middleware.

Ciclo di vita delle copie aggiornabili
A differenza di una versione di standby Oracle Data Guard tradizionale, le copie aggiornabili remote vengono abilitate separatamente e gestite separatamente da un database primario e in standby. Si tratta di un'entità separata con il proprio ciclo di vita oltre le operazioni di aggiornamento che la sincronizzano con il proprio database di origine (principale).
allocazione delle risorse CPU
Le copie aggiornabili remote non vengono create in base all'allocazione delle risorse CPU del sistema primario o in standby. Ciò significa che è necessario specificare le opzioni OCPU per la copia aggiornabile separatamente. È necessario configurare manualmente i test del carico di lavoro nella copia aggiornabile remota in modo che corrispondano alla capacità del sistema principale. È consigliabile creare la copia aggiornabile remota con una configurazione corrispondente al database primario in modo che il test dei carichi di lavoro sia realistico sul database secondario. Tuttavia, le copie aggiornabili remote "verificano" la configurazione di storage utilizzata nel database primario.
Applicazione di patch
Le patch vengono applicate automaticamente ogni settimana su Oracle Autonomous Database Serverless, in base alla finestra di manutenzione settimanale, in modo da garantire una sincronizzazione continua e efficace delle patch tra la copia aggiornabile primaria, in standby e remota.
Limiti del servizio
Le copie aggiornabili remote sono un'entità di prima classe, comportano un costo aggiuntivo in base alle implicazioni di storage, CPU e licenza di un Autonomous Database formale e verranno conteggiate ai fini dei limiti del servizio dell'area per Oracle Autonomous Database Serverless.
Copia aggiornabile allo switchover
Quando viene eseguito un failover o uno switchover "non reversibile" è necessario creare manualmente una copia aggiornabile sul database primario per mantenere il sistema pronto per le operazioni di test e manutenzione in quello che ora è il sistema secondario, con i limiti del servizio, la gestione e altre considerazioni appropriati. Nelle copie aggiornabili remote manca il controllo storno dei ruoli.

Dopo uno switchover al database secondario, la copia aggiornabile creata non sarà più in grado di eseguire l'aggiornamento (poiché l'origine è ora in standby) e viene contrassegnata come disconnessa. Dopo 24 ore diventa un clone non aggiornabile e disconnesso.
Finestra di aggiornamento delle copie aggiornabili
Le copie aggiornabili remote devono essere aggiornate almeno una volta alla settimana. In seguito, la sincronizzazione con i dati del database primario richiede la creazione di una nuova copia aggiornabile remota e l'eliminazione della copia non aggiornata.
Modalità di scrittura copie aggiornabili
Le copie aggiornabili remote non possono rimanere in modalità di scrittura (disconnettersi dal database primario) per più di 24 ore. Una volta trascorso tale periodo, il database delle copie aggiornabili remote non può essere nuovamente connesso al database primario. Dopo di che, per essere sincronizzati con i dati del database primario, è necessario creare una nuova copia aggiornabile remota ed eliminare quella non aggiornata.

Considerazioni per la posizione della cartella di configurazione `tns_admin`

Considerare quanto riportato di seguito per la cartella di configurazione tns_admin.

Utilizzare una posizione coerente per la cartella tns_admin
I livelli medi di un dominio WebLogic utilizzano una cartella per memorizzare il wallet di Oracle Autonomous Database e il file tnsnames.ora. La proprietà oracle.net.tns_admin punta a questa cartella nelle origini dati e nei file di configurazione jps. Il percorso di questa cartella deve essere lo stesso nei livelli intermedi primario e in standby. Se il percorso della cartella è diverso, modificarlo in primario o in standby in modo che utilizzino la stessa cartella prima di eseguire gli script di impostazione del disaster recovery (DR).
Nota:
Di seguito sono riportate le possibili differenze tra il database primario e quello in standby in questa posizione della cartella.
- Le istanze di Oracle SOA Suite su Marketplace di cui è stato eseguito il provisioning prima della fine di febbraio 2023 (prima della release 23.1.1) utilizzano $DOMAIN_HOME/config/atp per la cartella tns_admin. A partire dalla release 23.1.1, la posizione è $DOMAIN_HOME/config/tnsadmin.
La cartella tns_admin sotto la cartella del dominio config
Controllare la posizione del wallet di Oracle Autonomous Database nella configurazione dell'origine dati WebLogic. Se il wallet non si trova nella directory DOMAIN_HOME/config, le modifiche apportate al contenuto della directory del wallet NON verranno replicate automaticamente dall'infrastruttura Oracle WebLogic Server ad altri nodi. In questi casi, è necessario modificare la directory del wallet (e aggiornare le configurazioni delle origini dati necessarie) oppure copiarla manualmente in altri nodi quando viene aggiornata.