17.4 Maintaining DBFS
DBFS administration includes tools that perform diagnostics, manage failover, perform backup, and so on.
- Using Oracle Wallet with DBFS Client
Learn about using Oracle Wallet in this section. - DBFS Diagnostics
Thedbfs_client
program supports multiple levels of tracing to help diagnose problems. - Preventing Data Loss During Failover Events
Thedbfs_client
program can failover to one of the other existing database instances if one of the database instances in an Oracle RAC cluster fails. - Bypassing Client-Side Write Caching
The sharing and caching semantics fordbfs_client
are similar to NFS in using the close-to-open cache consistency behavior. - Backing up DBFS
You have two alternatives for backing up DBFS. - Small File Performance of DBFS
Like any shared file system, the performance of DBFS for small files lags the performance of a local file system.
Parent topic: Using DBFS
17.4.1 Using Oracle Wallet with DBFS Client
Learn about using Oracle Wallet in this section.
An Oracle Wallet allows the DBFS client to mount a DBFS store without requiring the user to enter a password.
See Also:
Oracle Database Enterprise User Security Administrator's Guide for more information about creation and management of wallets
Parent topic: Maintaining DBFS
17.4.2 DBFS Diagnostics
The dbfs_client
program supports multiple levels of tracing
to help diagnose problems.
The dbfs_client
can either output traces to a file or to
/var/log/messages
using the
syslog
daemon on Linux.
When you trace to a file, the dbfs_client
program keeps two trace
files on disk. dbfs_client
, rotates the trace files automatically, and
limits disk usage to 10 MB.
By default, tracing is turned off except for critical messages which are always logged to /var/log/messages
.
If dbfs_client
cannot connect to the Oracle Database, enable tracing using the trace_level
and trace_file
options. Tracing prints additional messages to log file for easier debugging.
DBFS uses Oracle Database for storing files. Sometimes Oracle server issues are propagated to dbfs_client
as errors. If there is a dbfs_client
error, please view the Oracle server logs to see if that is the root cause.
Parent topic: Maintaining DBFS
17.4.3 Preventing Data Loss During Failover Events
The dbfs_client
program can failover to one of the other existing database instances if one of the database instances in an Oracle RAC cluster fails.
dbfs_client
failover to work correctly, you must modify the Oracle database service and specify failover parameters. Run the DBMS_SERVICE.MODIFY_SERVICE
procedure to modify the service as shown Example 17-2Example 17-2 Enabling DBFS Client Failover Events
exec DBMS_SERVICE.MODIFY_SERVICE(service_name => 'service_name', aq_ha_notifications => true, failover_method => 'BASIC', failover_type => 'SELECT', failover_retries => 180, failover_delay => 1);
Once you have completed the prerequisite, you can prevent data loss during a failover of the DBFS connection after a failure of the back-end Oracle database instance. In this case, cached writes may be lost if the client loses the connection. However, back-end failover to other Oracle RAC instances or standby databases does not cause lost writes.
-
Specify the
-o failover
mount option:$ dbfs_client database_user@database_server -o failover /mnt/dbfs
Parent topic: Maintaining DBFS
17.4.4 Bypassing Client-Side Write Caching
The sharing and caching semantics for dbfs_client
are similar to NFS in using the close-to-open cache consistency behavior.
This allows multiple copies of dbfs_client
to access the same shared file system. The default mode caches writes on the client and flushes them after a timeout or after the user closes the file. Also, writes to a file only appear to clients that open the file after the writer closed the file.
You can bypass client-side write caching.
-
Specify
O_SYNC
when the file is opened.To force writes in the cache to disk call
fsync
.
Parent topic: Maintaining DBFS
17.4.5 Backing up DBFS
You have two alternatives for backing up DBFS.
You can back up the tables that underlie the file system at the database level or use a file system backup utility, such as Oracle Secure Backup, through a mount point.
Topics:
- DBFS Backup at the Database Level
An advantage of backing up the tables at the database level is that the files in the file system are always consistent with the relational data in the database. - DBFS Backup Through a File System Utility
The advantage of backing up the file system using a file system backup utility is that individual files can be restored from backup more easily.
Parent topic: Maintaining DBFS
17.4.5.1 DBFS Backup at the Database Level
An advantage of backing up the tables at the database level is that the files in the file system are always consistent with the relational data in the database.
A full restore and recover of the database also fully restores and recovers the file system with no data loss. During a point-in-time recovery of the database, the files are recovered to the specified time. As usual with database backup, modifications that occur during the backup do not affect the consistency of a restore. The entire restored file system is always consistent with respect to a specified time stamp.
Parent topic: Backing up DBFS
17.4.5.2 DBFS Backup Through a File System Utility
The advantage of backing up the file system using a file system backup utility is that individual files can be restored from backup more easily.
Any changes made to the restored files after the last backup are lost.
Specify the allow_root
mount option if backups are scheduled using the Oracle Secure Backup Administrative Server.
Parent topic: Backing up DBFS
17.4.6 Small File Performance of DBFS
Like any shared file system, the performance of DBFS for small files lags the performance of a local file system.
Each file data or metadata operation in DBFS must go through the FUSE
user mode file system and then be forwarded across the network to the database. Therefore, each operation that is not cached on the client takes a few milliseconds to run in DBFS.
For operations that involve an input/output (IO) to disk, the time delay overhead is masked by the wait for the disk IO. Naturally, larger IOs have a lower percentage overhead than smaller IOs. The network overhead is more noticeable for operations that do not issue a disk IO.
When you compare the operations on a few small files with a local file system, the
overhead is not noticeable, but operations that affect thousands of small files incur a
much more noticeable overhead. For example, listing a single directory or looking at a
single file produce near instantaneous response, while searching across a directory tree
with many thousands of files results in a larger relative overhead. Oracle recommends
direct_io
option in dbfs_client
for optimal
performance for reads and writes.
Parent topic: Maintaining DBFS