Informazioni su Oracle Database File System

Oracle Database File System (DBFS) sfrutta i vantaggi del database per memorizzare i file e i punti di forza del database nella gestione efficiente dei dati relazionali per implementare un'interfaccia di file system standard per i file memorizzati nel database. Con questa interfaccia, è possibile accedere in modo trasparente ai file nel database utilizzando qualsiasi programma del sistema operativo che agisca sui file.

DBFS è simile a NFS in quanto fornisce un file system di rete condiviso che sembra un file system locale e dispone sia di un componente server che di un componente client. È possibile eseguire il MOUNT del file system DBFS dagli host di livello intermedio e accedervi come file system condiviso normale.

DBFS introduce una certa complessità a causa della configurazione e della manutenzione richieste dal MOUNT DBFS. È necessario installare il client DB nell'host che lo installa ed eseguire un'impostazione iniziale di alcuni artifact nel database (tablespace, utente e così via) e nel client (wallet, tnsnames.ora e così via). Richiede capacità aggiuntiva nel database perché il contenuto copiato nel MOUNT DBFS viene memorizzato nel database.

Si sconsiglia di memorizzare la configurazione del dominio o i file binari direttamente nell'accesso DBFS. Ciò creerebbe una dipendenza molto forte tra i file di Oracle Fusion Middleware e il database. Tuttavia, le funzioni DBFS contengono alcuni artifact e operazioni che possono trarre vantaggio.

Informazioni sull'uso di DBFS per la cartella runtime

È possibile utilizzare un accesso a Oracle Database File System (DBFS) per i dati runtime condivisi come alternativa a NFS. Qualsiasi contenuto memorizzato nell'installazione DBFS risiede nel database e viene replicato automaticamente nel sito in standby tramite la replica di Oracle Data Guard di base. In questo modo, il sito secondario dispone sempre di una copia sincronizzata. Non è necessario configurare la replica aggiuntiva del contenuto runtime.

Per implementare questo approccio, installare il client DB in tutti gli host di livello intermedio (primario e secondario). È necessario eseguire un'impostazione iniziale di alcuni artifact nel database ( tablespace DBFS, utente e così via) e nel client (il wallet, tnsnames.ora e così via).

Vedere lo script dbfs_dr_setup_root.sh come script di esempio per configurare un accesso DBFS in un host di livello intermedio. Questo script installa il client del database, crea lo schema DBFS nel database, configura gli artifact del client ed esegue il MOUNT del file system DBFS in un host di livello intermedio.

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

Quando si utilizza questo script, considerare i punti riportati di seguito.

• La utility "yum" deve essere configurata correttamente nell'host prima di eseguire lo script. Lo script utilizza yum per scaricare alcuni package necessari per l'installazione del client DB.
• È necessario fornire i valori di ambiente (nomi utente, percorsi e così via) nella sezione "VARIABLES PERSONALIZZABILI" dello script.
• La variabile DBFS_CONFIG_DIR viene utilizzata per personalizzare la posizione degli artifact di configurazione DBFS (il wallet, tnsnames.ora e lo script per il MOUNT di DBFS). Utilizzare una posizione che non viene replicata tra i siti, quindi ogni sito dispone di una propria configurazione. Non posizionarla nella cartella del dominio perché verrà replicata in secondaria quando il dominio viene replicato.
• È necessario eseguire lo script negli host di livello intermedio principali (che puntano al database primario) e negli host di livello intermedio secondari (che puntano al database secondario). Verranno visualizzate avvertenze perché alcune cose sono già state create (utente DB, tablespace e così via), ma è possibile ignorare questi messaggi.
• Per eseguire la configurazione negli host di livello intermedio secondari, è necessario aprire il database di standby in modalità standby snapshot. Ciò accade perché è possibile eseguire il MOUNT del file DBFS solo quando il database è aperto. Quando Oracle Data Guard non è un servizio Active Data Guard, lo stato del database in standby è MOUNT. Per accedere al MOUNT DBFS nel sito in standby in questi casi, devi convertire il database in standby snapshot.

Una volta configurato l'accesso DBFS in tutti gli host di livello intermedio, è possibile utilizzarlo come cartella condivisa per i dati runtime, ad esempio per i file letti/scritti da un adattatore di file o da un'applicazione personalizzata. Non è necessario replicare manualmente questo contenuto nel sito secondario. Il contenuto viene replicato automaticamente con Oracle Data Guard. Se si verifica uno switchover o un failover, il contenuto runtime è disponibile nel nuovo database primario insieme al resto delle informazioni memorizzate nel database.

Vantaggi dell'utilizzo dell'accesso DBFS per i dati runtime:

• La replica tra siti è implicita. Il contenuto memorizzato nel MOUNT DBFS nel sito primario viene replicato nel sito secondario tramite Oracle Data Guard.

Svantaggi:

• Le prestazioni DBFS sono peggiori rispetto alle soluzioni NFS (Oracle Cloud Infrastructure File Storage, Oracle ZFS).
• Oracle consiglia di eseguire il MOUNT di dbfs nel nuovo database primario dopo uno switchover per assicurarsi che l'accesso DBFS sia in buono stato. L'accesso DBFS può diventare non più valido e richiedere un remount se il database a cui punta non è aperto per un certo periodo di tempo (ad esempio, mentre il database è in modalità standby).

Informazioni sull'uso di DBFS per replicare la configurazione di Oracle WebLogic Server

Oracle Database File System (DBFS) è un altro metodo che è possibile utilizzare per replicare la configurazione. In questo caso, è possibile utilizzare un accesso DBFS come posizione intermedia per replicare la configurazione. Qualsiasi contenuto memorizzato nel MOUNT DBFS risiede nel database e viene replicato automaticamente nel sito in standby tramite la replica di Oracle Data Guard di base.

Questo metodo sfrutta la robustezza della replica di Oracle Data Guard. Dispone di una buona disponibilità grazie alla logica dei nuovi tentativi di Oracle Driver e offre un funzionamento resiliente. Puoi utilizzarlo in scenari con latenze medie o elevate tra i data center. Tuttavia, l'utilizzo di DBFS per la replica della configurazione comporta implicazioni aggiuntive rispetto alle prospettive a livello di impostazione, storage del database e ciclo di vita.

• Introduce una certa complessità a causa della configurazione e della manutenzione richieste dal MOUNT DBFS. Richiede l'installazione del client DB nell'host che verrà montato, richiede l'impostazione iniziale di alcuni artifact nel database (tablespace, utente e così via) e nel client (il wallet, tnsnames.ora e così via). Vedere lo script dbfs_dr_setup_root.sh come uno script di esempio che installa il client del database, crea lo schema DBFS nel database, configura gli artifact del client ed esegue il MOUNT del file system DBFS in un host di livello intermedio.
• Richiede capacità aggiuntiva nel database perché il contenuto copiato nel MOUNT DBFS viene memorizzato nel database.
• Si sconsiglia di memorizzare la configurazione del dominio o i file binari direttamente nell'accesso DBFS. Ciò crea una dipendenza molto forte tra i file di Oracle Fusion Middleware e il database. Si consiglia invece di utilizzare DBFS come file system assistance: file system di staging intermedio per posizionare le informazioni che verranno replicate nel sito in standby. La replica nel database in standby prevede due passi: dalla cartella di origine del database primario all'installazione DBFS intermedia e quindi, nel sito in standby, dall'installazione DBFS alla cartella di destinazione del database in standby.
• È possibile eseguire il MOUNT del file DBFS solo quando il database è aperto. Quando Oracle Data Guard non è un servizio Active Data Guard, lo stato del database in standby è MOUNT. Di conseguenza, per accedere al MOUNT DBFS nel sito in standby in questi casi, è necessario convertire il database in standby snapshot. Quando si utilizza Active Data Guard, è possibile eseguire il MOUNT del file system per le letture e non è necessario eseguire la transizione allo snapshot.

Per questi motivi, DBFS non è consigliato come soluzione generica per replicare tutti gli artifact del file system nel database in standby. Ad esempio, si tratta di un sovraccarico per replicare i file binari con DBFS.

Tuttavia, questo approccio è adatto per replicare alcuni artifact dinamici durante il ciclo di vita, come la configurazione condivisa del dominio (ASERVER_HOME), quando altri metodi come la replica dello storage o rsync non sono realizzabili. Per un esempio su come utilizzare DBFS come file system di assistenza per replicare la configurazione del dominio, consultare il documento Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery.

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