About Oracle Database File System
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
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
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 scriptdbfs_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.