About Oracle Database File System

Oracle Database File System (DBFS) leverages the benefits of the database to store files, and the strengths of the database in efficiently managing relational data to implement a standard file system interface for files stored in the database. With this interface, files in the database can be transparently accessed using any operating system program that acts on files.

DBFS is similar to NFS in that it provides a shared network file system that looks like a local file system, and has both a server component and a client component. The DBFS file system can be mounted from the mid-tier hosts and accessed as a regular shared file system.

DBFS introduces some complexity due to the configuration and maintenance required by the DBFS mount. You must install the DB client in the host that mounts it, and you must perform an initial setup of some artifacts in the database (tablespace, user, and so on) and in the client (the wallet, the tnsnames.ora, and so on). It requires additional capacity in the database because the content copied to the DBFS mount is stored in the database.

It is not recommended to store the domain configuration or the binaries directly in the DBFS mount. This would create a very strong dependency between the Oracle Fusion Middleware files and the database. However, there are some artifacts and operations than can benefit from the DBFS features.

About Using DBFS for the runtime Folder

You can use an Oracle Database File System (DBFS) mount for the shared runtime data as an alternative to NFS. Any content stored in the DBFS mount resides in the database and is automatically replicated to the standby site through the underlying Oracle Data Guard replication. This way, secondary site always has a synchronized copy of it. You do not need to configure additional replication of the runtime content.

To implement this approach, install the DB client in all of the mid-tier hosts (primary and secondary). You must perform an initial setup of some artifacts in the database (DBFS tablespace, user, and so on) and in the client (the wallet, the tnsnames.ora, and so on).

See the script dbfs_dr_setup_root.sh as an example script to configure a DBFS mount in a mid-tier hosts. This script installs the database client, creates the DBFS schema in the database, configures the client artifacts, and mounts the DBFS file system in a mid-tier host.

Go to Download Code for the link to download the script.

Consider the following points when using this script:

• The “yum” utility must be correctly configured in the host before you run the script. The script uses yum to download some packages required for the DB client installation.
• You must provide your environment values (user names, paths, etc.) in the “CUSTOMIZABLE VARIABLES” section of the script.
• The variable DBFS_CONFIG_DIR is used to customize the location of the DBFS configuration artifacts (the wallet, the tnsnames.ora and the script to mount DBFS). Use a location that is not replicated between sites, so each site has its own configuration. Do not place it under the domain folder, because it will be replicated to secondary when the domain is replicated.
• You must run the script in primary mid-tier hosts (pointing to the primary database), and in the secondary mid-tier hosts (pointing to the secondary database). You will see warnings because some things are already created (db user, tablespace, etc.), but you can ignore these messages.
• To perform the configuration in the secondary mid-tier hosts, the standby database must be opened in snapshot standby mode. This is because the DBFS can be mounted only when the database is open. When Oracle Data Guard is not an Active Data Guard, the standby database is in mount state. To access to the DBFS mount in the standby site in such cases, you must convert the database to snapshot standby.

Once the DBFS mount is configured in all the mid-tier hosts, you can use it as a shared folder for the runtime data (for example, for files that are read/written by a file adapter or custom application). You do not have to manually replicate this content to the secondary site, it is automatically replicated with Oracle Data Guard. If a switchover or failover happens, then the runtime content is available in the new primary along with the rest of the information stored in the database.

Advantages of using DBFS mount for the runtime data:

• Replication between sites is implicit. The content stored in the DBFS mount in primary site is replicated to secondary site through Oracle Data Guard.

Disadvantages:

• DBFS performance is worse than in NFS solutions (Oracle Cloud Infrastructure File Storage, Oracle ZFS).
• Oracle recommends you remount dbfs in the new primary after a switchover, to make sure that the DBFS mount is healthy. The DBFS mount can become stale and require a remount if the database it points to was not open for some time (For example, while the database is in standby mode).

About Using DBFS to replicate the Oracle WebLogic Server Configuration

Oracle Database File System (DBFS) is another method that you can use to replicate the configuration. In this case, you can use a DBFS mount as an intermediate location to replicate the configuration. Any content stored in the DBFS mount resides in the database and is automatically replicated to the standby site through the underlying Oracle Data Guard replication.

This method takes advantage of the robustness of Oracle Data Guard replica. It has good availability through Oracle Driver’s retry logic and provides a resilient behavior. You can use it in scenarios with medium or high latencies between the data centers. However, using DBFS for configuration replication has additional implications from the setup, database storage, and lifecycle perspectives:

• It introduces some complexity due to the configuration and maintenance required by the DBFS mount. It requires the DB client to be installed in the host that is going to mount it, it requires an initial setup of some artifacts in the database (tablespace, user, and so on) and in the client (the wallet, the tnsnames.ora, and so on). See the script dbfs_dr_setup_root.sh as an example script that installs the database client, creates the DBFS schema in the database, configures the client artifacts, and mounts the DBFS file system in a mid-tier host.
• It requires additional capacity in the database because the content copied to the DBFS mount is stored in the database.
• It is not recommended to store the domain configuration or the binaries directly in the DBFS mount. This creates a very strong dependency between the Oracle Fusion Middleware files and the database. Instead, it is recommended to use the DBFS as an assistance file system: an intermediate staging file system to place the information that is going to be replicated to the standby site. Replication to the standby has two steps: from the primary's origin folder to the intermediate DBFS mount, and then, in the standby site, from the DBFS mount to the standby's destination folder.
• The DBFS can be mounted only when the database is open. When Oracle Data Guard is not an Active Data Guard, the standby database is in mount state. Hence, to access to the DBFS mount in the standby site in such cases, the database must be converted to snapshot standby. When Active Data Guard is used, the file system can be mounted for reads and there is no need to transition to snapshot.

For these reasons, DBFS it is not recommended as a general-purpose solution to replicate all the file system artifacts to the standby. For example, it is an overkill to replicate the binaries with DBFS.

However, this approach is suitable to replicate some dynamic artifacts during the lifecycle, such as the domain shared configuration (ASERVER_HOME), when other methods like the storage replication or rsync are not feasible. See the Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery paper to see an example on how to use DBFS as an assistance file system to replicate the domain configuration.

Go to Download Code for the link to download the script.