18.5 Maintaining DBFS

DBFS administration includes tools that perform diagnostics, manage failover, perform backup, and so on.

18.5.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. Enterprise User Security (EUS) is deprecated with Oracle Database 23ai.

  1. Create a directory for the wallet. For example:
    mkdir $ORACLE_HOME/oracle/wallet
    
  2. Create an auto-login wallet.
    mkstore -wrl $ORACLE_HOME/oracle/wallet -create
    

    The mkstore wallet management command line tool is deprecated with Oracle Database 23ai, and can be removed in a future release.

  3. Add the wallet location in the client's sqlnet.ora file:
    WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY =
     $ORACLE_HOME/oracle/wallet) ) ) 
    
  4. Add the following parameter in the client's sqlnet.ora file:
    SQLNET.WALLET_OVERRIDE = TRUE
    
  5. Create credentials:
    mkstore -wrl wallet_location -createCredential db_connect_string username password
    

    For example:

    mkstore -wrl $ORACLE_HOME/oracle/wallet -createCredential DBConnectString scott password
    
  6. Add the connection alias to your tnsnames.ora file.
  7. Use dbfs_client with Oracle Wallet.

    For example:

    $ dbfs_client -o wallet /@DBConnectString /mnt/dbfs 

18.5.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.

Note:

The diagnostic_dest initialization parameter sets the location of the automatic diagnostic repository. When you use dbfs_client or Oracle File Server (OFS) as the file system server, ensure that this parameter does not point to a directory inside dbfs_client or OFS as this can produce a dependency cycle and cause the system to hang.

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.

18.5.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.

For 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 18-2

Example 18-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 

18.5.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.

18.5.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:

18.5.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.

18.5.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.

18.5.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.